Closed
Bug 210734
Opened 21 years ago
Closed 21 years ago
IDN: Invalid codepoint encoded in ACE label
Categories
(Core :: Internationalization, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla1.5alpha
People
(Reporter: yone, Assigned: darin.moz)
References
Details
(Keywords: fixed1.4.1)
Attachments
(1 file)
983 bytes,
patch
|
nhottanscp
:
review+
bzbarsky
:
superreview+
asa
:
approval1.4.1+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 When users entered Alphabet or Numerics in compatible (i.e Full-Width) form, the resulting ACE label (both Punycode and RACE) includes 0x0 in it. For example: www.U+FF4A U+FF44 U+FF4E U+FF41.jp is expected to be nameprepped and changed into www.jdna.jp, but the result is www.xn--jdna-.jp. Reproducible: Always Steps to Reproduce: 1. enter www.jdna.jp at address bar 2. 3. Actual Results: the entered address was changed into www.xn--jdna-.jp, and DNS fails Expected Results: jdna part should be nameprepped into jdna, i.e. www.jdna.jp
Comment 1•21 years ago
|
||
Confirmed. When we use Japanese Roman letters (either upper case or lowercase), NamePrep does not produce the correct result.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•21 years ago
|
||
Another example is "maß", i.e. "bei U+00DF"; during NamePrep, the german double s is converted into two s and no non-LDH character remains. So it should not be converted to Punycode after the normalization, opposite to how it is done (xn--mass-).
Comment 3•21 years ago
|
||
Sorry, the example went wrong: it is maß -> U+006D U+0061 U+00DF
Assignee | ||
Comment 4•21 years ago
|
||
We branch into IDN code whenever a hostname contains non-ASCII codepoints. So, it seems to me that as a last step, our IDN converter needs to verify that the nameprepped hostname also contains non-ASCII values before we tack on the xn-- prefix. If I am correct, then this should be fairly easy to fix.
Assignee | ||
Comment 5•21 years ago
|
||
Assignee | ||
Comment 6•21 years ago
|
||
-> me
Assignee: smontagu → darin
Severity: normal → major
Priority: -- → P1
Target Milestone: --- → mozilla1.5alpha
Assignee | ||
Updated•21 years ago
|
Attachment #127174 -
Flags: review?(nhotta)
Comment 7•21 years ago
|
||
Darin, I tried your patch on Mozilla 1.4 branch with the example filed by the reporter. It works when the patch is applied. I also tried a case when the user enters www.(JPN name).jp (in JPN full- width Roman characters), this too works with the patch. Klaus, Yoneya-san, and others, please supply other real life examples for verification. Thanks.
Comment 8•21 years ago
|
||
Comment on attachment 127174 [details] [diff] [review] v1 patch r=nhotta
Attachment #127174 -
Flags: review?(nhotta) → review+
Assignee | ||
Comment 9•21 years ago
|
||
Comment on attachment 127174 [details] [diff] [review] v1 patch bz: please see comment #4 for an explanation of this patch.
Attachment #127174 -
Flags: superreview?(bzbarsky)
Comment 10•21 years ago
|
||
I wonder if full-width alphabet only domain names are accepted for registration. I am not sure about the official guideline but I think that could be confusing (also a risk for spoofing). Yoneya san, does JPNIC allow those string for the registration?
Updated•21 years ago
|
Attachment #127174 -
Flags: superreview?(bzbarsky) → superreview+
Assignee | ||
Comment 11•21 years ago
|
||
fixed-on-trunk
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 12•21 years ago
|
||
This is re-comment to comment #10. JPRS (is JP registory since Apr 2002) accepts full-width Alpha-Numerics in inputted string for registration. But those are NAMEPREPped by registration system at the registration time and never appear in registered domain name. Allowed Japanese characters for JP domain name are listed on draft-yoneya-idn-jachar-00.txt
Assignee | ||
Comment 13•21 years ago
|
||
i think this patch should be included with any future 1.4 branch releases.
Flags: blocking1.4.x?
Assignee | ||
Comment 14•21 years ago
|
||
*** Bug 211320 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 15•21 years ago
|
||
Comment on attachment 127174 [details] [diff] [review] v1 patch this is an important bug to get fixed on the 1.4 branch. it prevents IDN from working with many sites.
Attachment #127174 -
Flags: approval1.4.x?
Comment 16•21 years ago
|
||
Comment #15 is so true that we should definitely check this into 1.4 so that any future releases from 1.4 can benefit from this fix.
Reporter | ||
Comment 17•21 years ago
|
||
Thanks to all, I found this bug was fixed in 20030708 trunk. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030708
Updated•21 years ago
|
Flags: blocking1.4.x? → blocking1.4.x+
Comment 18•21 years ago
|
||
Comment on attachment 127174 [details] [diff] [review] v1 patch a=asa (on behalf of drivers) for checkin to the 1.4 branch.
Attachment #127174 -
Flags: approval1.4.x? → approval1.4.x+
Updated•21 years ago
|
Keywords: fixed1.4 → fixed1.4.1
You need to log in
before you can comment on or make changes to this bug.
Description
•