Open Bug 1365893 Opened 7 years ago Updated 2 years ago

Apply IDNA ToASCII even when the input is ASCII

Categories

(Core :: Networking, defect, P3)

defect

Tracking

()

People

(Reporter: annevk, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [necko-backlog])

If ToASCII is not applied to all input (even ASCII) rules are not uniformly enforced. E.g., it means that Unicode labels can be 63 code points after conversion to Punycode, whereas ASCII labels have no limit.

Making it uniform likely requires removing some rules for non-ASCII input, as the web depends on being able to place hyphens in the 3rd and 4th place of a label, and likely also depends on leading and trailing hyphens.

An update to Unicode's UTS #46 likely makes more of this configurable: http://www.unicode.org/reports/tr46/tr46-18.html.

https://url.spec.whatwg.org/#idna already requires UseSTD3ASCIIRules and VerifyDnsLength to be set to false. I propose that the URL Standard also sets CheckHyphens (needed for compatibility) and CheckJoiners (seems silly to restrict a subset of emojis) to false and continues to require applying ToASCII (domain to ASCII as the URL Standard calls it) to all input.

Tests: https://github.com/w3c/web-platform-tests/pull/5976.
Blocks: 423287
Whiteboard: [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Blocks: url
Doesn't UseSTD3ASCIIRules reject underscores, which are used on some networks?
Florian, that's why it's set to false, indeed.

I suspect we want to see https://github.com/whatwg/url/labels/topic%3A%20idna solved before tackling this and also see changes in other browsers.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.