Closed Bug 43659 Opened 20 years ago Closed 4 years ago

URL: hexadecimal encoded domain names not supported

Categories

(Core :: Networking, defect, P3)

x86
All
defect

Tracking

()

RESOLVED DUPLICATE of bug 412457

People

(Reporter: sarah.livengood, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: helpwanted, Whiteboard: [necko-would-take])

Attachments

(1 file)

When using IE5, I am able to type URLs in the form of hexadecimal notation 
(i.e. - typing  www.%69%6e%74%65%6c.com for www.intel.com) and it would take me 
to the web page.  However, in Mozilla this is not working..I could see on the 
bottom status bar that it was atleast trying to interpret the hexadecimal 
string but it could not interpret the last character (i.e. translated www.%69%
6e%74%65%6c.com to www.inte%6c.com ).
why is this an editor bug? assigning to networking due to url string resolution
Component: Editor → Networking
assigning to networking modular owner
Assignee: beppe → gagan
Confirming bug. Reproduced on PC/Linux, build 2000062220.
When I paste www.%69%6e%74%65%6c.com into the url bar, 
I get an error dialog stating that www.i%6ete%6c.com could not be found.
Maybe this is a problem with letters in hex numbers (a-f)?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Oh yes, sometimes I'm so dumb. This is mine ...
fix checked in 
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
tever this one is for you...
QA Contact: sujay → tever
Believe this might have regressed.

To use above orginal example:

www.%69%6e%74%65%6c.com <---www.intel.com

!ALERT: Could not find name ..... Please check url and try again.  

This fails and so has every other test case I have tried.

From what I can tell watching the bottom status, it doesn't even attempt to
resolve it.

Build: Mozilla 1.1 Release
OS: w2k server SP3

As far as I can see, the host no longer gets unescaped and resolving the escaped
host gets no result. My guess is that this has something to do with support for
non ascii chars in domainnames.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
reassigning for new evaluation
Assignee: gagan → new-network-bugs
Status: REOPENED → NEW
QA Contact: tever → benc
If this is necko, not just URL bar, can we update the summary? Otherwise, if it
is URL bar, lets send it to them (and please change the QA assignment as well).
changing summary
Summary: URL bar does not accept hexadecimal domain names → necko does not accept hexadecimal domain names
+helpwanted.
andreas and the other necko engineers will probably want to figure this out
sooner, rather than later. I am not IDN-saavy, so I have no firm opinion at this
time.
Keywords: helpwanted
ccing darin for some info on the status of IDN
we decided to not unescape hostnames since it has led to security fire drills so
many times in the past.  consider the hostname www.foo.com%00www.bar.com, for
example.  as soon as we try to unescape a hostname, we have to be sure to
properly validate it (i.e., we have to reject null characters and the like after
unescaping).  this can be tricky so it was decided to drop unescaping of the
hostname.  in most cases, this is acceptable since there is no engineering need
or requirement to support escaped hostname characters.  however, we have also
made significant steps toward making more code use nsIURI for URL parsing, which
means that we could look at making URL normalization unescape characters in the
hostname w/ proper sanity checks of course.

-> me (i'll look into this for moz 1.3)
Assignee: new-network-bugs → darin
Target Milestone: --- → mozilla1.3alpha
Status: NEW → ASSIGNED
Target Milestone: mozilla1.3alpha → mozilla1.3beta
Summary: necko does not accept hexadecimal domain names → URL: hexadecimal encoded domain names
Target Milestone: mozilla1.3beta → mozilla1.4alpha
Target Milestone: mozilla1.4alpha → mozilla1.4beta
*** Bug 212891 has been marked as a duplicate of this bug. ***
Summary: URL: hexadecimal encoded domain names → URL: hexadecimal encoded domain names not supported
Assignee: darin → nobody
Status: ASSIGNED → NEW
QA Contact: benc → networking
Target Milestone: mozilla1.4beta → ---
Adding dependency on bug 355425, which addresses some of the issues raised in Comment #15.
Depends on: 355425
Duplicate of this bug: 947183
Flags: needinfo?(valentin.gosu)
is this wontfix?
Whiteboard: [necko-would-take]
Actually, this was fixed recently.
Duping to bug 412457.
Status: NEW → RESOLVED
Closed: 20 years ago4 years ago
Flags: needinfo?(valentin.gosu)
Resolution: --- → DUPLICATE
Duplicate of bug: 412457
You need to log in before you can comment on or make changes to this bug.