43659 - URL: hexadecimal encoded domain names not supported

Status: RESOLVED DUPLICATE of bug 412457

(Core :: Networking, defect, P3)

Description

[Sarah Livengood]

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 ).

Comment 1

[rubydoo123]

why is this an editor bug? assigning to networking due to url string resolution

Comment 2

[rubydoo123]

assigning to networking modular owner

Comment 3

[Andreas Franke (gone)]

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)?

Comment 4

[Andreas Otte]

Oh yes, sometimes I'm so dumb. This is mine ...

Comment 5

[Andreas Otte]

Attachment: Patch to fix the problem

Comment 6

[Andreas Otte]

fix checked in 

Comment 7

[sujay]

tever this one is for you...

Comment 8

[u17130]

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

Comment 9

[Andreas Otte]

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.

Comment 10

[Andreas Otte]

reassigning for new evaluation

Comment 11

[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).

Comment 12

[Andreas Otte]

changing summary

Comment 13

[benc]

+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.

Comment 14

[Andreas Otte]

ccing darin for some info on the status of IDN

Comment 15

[Darin Fisher]

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)

Comment 16

[Jo Hermans]

*** Bug 212891 has been marked as a duplicate of this bug. ***

Comment 17

[Neil Harris]

Adding dependency on bug 355425, which addresses some of the issues raised in Comment #15.

Comment 19

[Patrick McManus [:mcmanus]]

is this wontfix?

Comment 20

[Valentin Gosu [:valentin] (he/him)]

Actually, this was fixed recently.
Duping to bug 412457.