Closed
Bug 157388
Opened 22 years ago
Closed 21 years ago
Can't open .nu domains with the danish characters זר�Ein them (gives a "זר�Enu could not be found" error)
Categories
(Core :: Internationalization, defect)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: stig, Assigned: nhottanscp)
References
()
Details
Attachments
(1 file, 1 obsolete file)
45.27 KB,
image/png
|
Details |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
BuildID: 2002053012
Can't open .nu domains with the danish characters æøå in them. æøå are alloved
in .nu domains and it works in Internet Explorer. Mozilla 1.0 gives the error:
"æøå.nu could not be found. Please check the name and try again".
Some examples:
http://tjæreborg.nu/
http://føtex.nu/
http://ørestadsselskabet.nu/
Reproducible: Always
Steps to Reproduce:
(try to) go to http://ørestadsselskabet.nu/
Actual Results: Mozilla 1.0 gives the error: "http://ørestadsselskabet.nu/
could not be found. Please check the name and try again".
Expected Results: Mozilla should display the content of
http://ørestadsselskabet.nu/
Comment 1•22 years ago
|
||
WFM, Build 2002071208, Win 98
Comment 2•22 years ago
|
||
Gives error message on Mozilla 1.1a+
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020711
However I do not comment, what should have result.
Updated•22 years ago
|
OS: Windows 98 → All
Comment 3•22 years ago
|
||
Hmm. Looks like that domain name is with ISO-8859-1 characters or at least
it also with ISO-8859-1 characters.
[hurtta@pontus hurtta]$ nslookup -q=any 'tjæreborg.nu'
Server: ns.tele.fi
Address: 193.210.18.18
tj\230reborg.nu internet address = 64.55.105.9
tj\230reborg.nu internet address = 212.181.91.6
Did not checked is that domain name also with some other presentation.
(ISO-8859-1 sure is not charset of DNS.)
Comment 4•22 years ago
|
||
WFM Mozilla 1.1a+, build 2002071008 (almost 1.1b) on MacOS 9
I can see all 3 webpages, which are reserved by nunames.nu, but not yet assigned.
It didn't work when I used my proxy-server proxy.wanadoo.be (Squid/2.4.STABLE7),
but it worked when I connect directly to the domain.
Comment 5•22 years ago
|
||
Eh ... wait a minute. I check if Mac IE 5 could access the page (after disabling
the proxyserver for that one too), and I got a different result
http://tjæreborg.nu/ shows me a page from a travle agency. In Mozilla, I can
only see a "This domain name, "nu", may still be available for registration!" page.
I've seen the same behaviour with the other addresses, and with other domains
that I found on nunames.nu (like http://domän.nu/). I think that nunames.nu is
doing some browser-sniffing, or maybe Mozilla send the request slighly differently.
Reporter | ||
Comment 6•22 years ago
|
||
I just download'ed the latest trunk build and tried that. My previous testing
was only with the Mozilla 1.0 release. It doesn't work correctly in either, but
the behavoir is different. In Mozilla 1.0 i get the previous described alert
("זרו.nu could not be found. Please check the name and try again") and in the
2002071404 build i get the nunames.nu-page telling:
This domain name, "nu", may still be available for registration!...
I don't use proxy in either browser, and it works correctly for me in both
Internet Explorer 5.5 and Opera 6.01 (same PC and OS).
Comment 7•22 years ago
|
||
Well, view selection source shows links on this bug page as
<a href="http://%C3%B8restadsselskabet.nu/">http://ørestadsselskabet.nu/</a>
and when viewing cursor over that link on status bar is show that link
as it is ISO-8859-1. So these "This domain name ... available for registration"
may be that represtation what mozilla uses is not registered.
(Odd status bar I filed as bug 157392.)
However this is not exactly latst trunk build (Build ID 22071104).
IETF working group "idn" (Internationalized Domain Name) is not yet have
finished work about subject so there is no standard yet.
(See: http://www.ietf.org/html.charters/idn-charter.html )
Comment 8•22 years ago
|
||
With Build ID 2002071404, Mozilla 1.1a+
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020714
error message is little different. On that case it is
show as UTF-8 text is show as it is ISO-8859-1 charset
(or something like that.)
Attachment #91268 -
Attachment is obsolete: true
Comment 9•22 years ago
|
||
For Url''s mozilla seems use presentation what
"Internationalized Domain Names in URIs draft-ietf-idn-uri-02"
http://www.ietf.org/internet-drafts/draft-ietf-idn-uri-02.txt gives:
"Characters outside the repertoire (alphanum) are encoded by first
encoding the characters in UTF-8 [RFC 2279], resulting in a sequence
of octets, and then escaping these octets according to the rules
defined in [RFC2396]."
However for DNS that is further translated "For domain names
containing non-ASCII characters, the legal domain names are those for
which the ToASCII operation ([IDNA], [Nameprep]; using the unescaped
UTF-8 values as input) is successful."
"Nameprep: A Stringprep Profile for Internationalized Domain Names"
http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-11.txt
mostly refers to another draft.
"Internationalizing Domain Names in Applications (IDNA)"
http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-10.txt says
"To allow internationalized labels to be handled by existing
applications, IDNA uses an "ACE label" (ACE stands for ASCII Compatible
Encoding), which can be represented using only ASCII characters but is
equivalent to a label containing non-ASCII characters."
Comment 10•22 years ago
|
||
Comment 11•22 years ago
|
||
Also "Transitional Reflexive ACE -- IDN Transition (IDNX)"
http://www.ietf.org/internet-drafts/draft-ietf-idn-dnsii-trace-01.txt
suggest:
"In other words, the registry should be prepared to accept and resolve
multilingual domain requests from users with existing software when
they deploy and offer multilingual domain registrations to
registrants. "
"In general, there are three types of IDN requests that a registry
server may receive: 1. Domain in the form of UTF8 encoding; 2. Domain
in the form of its local encoding (GB, Big-5, JIS, KSC, ISO8859-1..13
etc.); 3. Domain is in an ACE (ASCII Compatible Encoding) format."
So quering UTF8 (instead of ACE) from DNS is not that bad :-)
And you can not use ACE (yet) because there is several different suggestion
for ACE (ie. different algorithm are proposed.)
Updated•22 years ago
|
Summary: Can't open .nu domains with the danish characters זרו in them (gives a "זרו.nu could not be found" error) → Can't open .nu domains with the danish characters זר�Ein them (gives a "זר�Enu could not be found" error)
Reporter | ||
Comment 12•22 years ago
|
||
Another test-link:
http://www.bravå.nu/
None of the other test-links included the character "å" which just might give
extra problems ? (I noticed this character changed in the summary when
yokoyama@netscape.com added himself to the CC-list!)
Comment 13•22 years ago
|
||
-> nhotta
Assignee: darin → nhotta
Component: Networking: HTTP → Internationalization
Assignee | ||
Comment 14•22 years ago
|
||
> 1. Domain in the form of UTF8 encoding;
> 2. Domain in the form of its local encoding (GB, Big-5, JIS, KSC, ISO8859-1..13
> etc.);
> 3. Domain is in an ACE (ASCII Compatible Encoding) format."
Mozilla's current direction is to support #3 (bug 112979).
We need to decide how to deal with other cases (but I think #2 would not be
supported).
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment 15•22 years ago
|
||
.nu now supports IDNA; the test URL of this report is accessible as
http://xn--tjreborg-k0a.nu
Therefore, I would advise against taking any other approach in Mozilla beyond
#3. It is likely that all other major registrars supporting non-ASCII domain
names will support IDNA in the very near future.
Reporter | ||
Comment 16•21 years ago
|
||
Maybe this bug should be marked as fixed? All my original example links opens
correctly now (and has for some time). It looks a bit weird it says
http://xn--tjreborg-k0a.nu in the adressbar and not just http://tjæreborg.nu,
but I don't care much about that. There's much more important issues in Mozilla
to use the time on :-) For me this bug is fixed.
Comment 17•21 years ago
|
||
yeah, WFM too (winxp 20030701 firebird trunk)... i agree that the status bar
issue should probably be filed as a separate bug.
Comment 18•21 years ago
|
||
This bug worksforme with Windows Seamonkey builds 2004020909
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Comment 19•21 years ago
|
||
*** Bug 162571 has been marked as a duplicate of this bug. ***
Comment 20•21 years ago
|
||
V WFM, Mozilla 1.6, Mac OS X.
Status: RESOLVED → VERIFIED
QA Contact: tever → benc
You need to log in
before you can comment on or make changes to this bug.
Description
•