122965 - Correcting backslashes will make uppercase letters change in lowercase

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[j. Wiskerke]

On the url there is a dutch page with 2 links. 
The links have the wrong kind of slashes. The first link is:
"http:\\home.student.utwente.nl\g.p.willering\opengaan\Opengaan.htm".

When you click on this link Mozilla will convert this to:
"http://home.student.utwente.nl/g.p.willering/opengaan/opengaan.htm/"
which has lowercase 'o' in "opengaan" and contains a slash on the end.
Both will result in showing an errorpage.

Comment 1

[[e-mail]]

Reproduced in build 2002013103 on Windows NT.

The expected URL (which does work) is
http://home.student.utwente.nl/g.p.willering/opengaan/Opengaan.htm

Comment 2

[Boris Zbarsky [:bzbarsky]]

andreas, shouldn't this not be happening at all?

Comment 3

[Andreas Otte]

No, it shouldn't. Where is this comming from? I will investigate ...

Comment 4

[Andreas Otte]

There is something strange going on ... apparently the whole
home.student.utwente.nl\g.p.willering\opengaan\Opengaan.htm is taken as host
name as it should happen. Signs for this are:

1. Adding a / at the end as it should happen with a missing directory (only host
given)

2. lowercasing as it should happen with hostnames

So far so good ... what I can't figure out at the moment, is where the
conversion from \ to / happens. I don't think it happens in the urlparser, there
is no longer any code in there that can do that. Must be docshell or something
above.

Comment 5

[Andreas Otte]

There still is some conversion stuff in docshell. See bug 122270 for a recent
discussion on the subject. I'm all for removing it.

In this case could be that docshell gets the mangled url and then trys it's
urifixup on it. This way 

http:\\home.student.utwente.nl\g.p.willering\opengaan\Opengaan.htm

becomes first (through the urlparser):

http://home.student.utwente.nl\g.p.willering\opengaan\opengaan.htm/

and then (urifixup on windows):

http://home.student.utwente.nl/g.p.willering/opengaan/opengaan.htm/

In any case and first of all this is something for tech evangelism.

Comment 6

[Joe Hewitt (gone)]

Strangely, this bug doesn't occur if you open the link in a new window/tab.

looks like a docshell bug, not urlbar

Comment 7

[Adam Lock]

This should not be anything to do with URI fixup. URI fixup only happens when
you type directly into the URL address bar.
If the user is clicking on the link, then it indicates an issue with URI parsing.

Comment 8

[Adam Lock]

-> Darin

URI is not touched by URI fixup when clicked on as a link. Even when it is fixed
up, the case of the URL is not changed by the URI fixup code.

Comment 9

[Andreas Otte]

As I indicated earlier:

1. There is no longer any code in the urlparser that changes \ to /. That's a
fact. Believe it Adam!

2. The case change happens in the urlparser because of that, since the \ are
read as normal characters, the whole thing (that is supposed to be the path and
filename) is taken as host and according to the rules for hosts is lowercased.

So far all is fine. There is no error here!!!!!!!! Of course we get a DNS error
on this since home.student.utwente.nl\g.p.willering\opengaan\opengaan.doc is no
valid host. 

Adam is correct, we don't go through docshell when clicking on a link, at least
not upfront.

And on this circumstances (as far as I can tell, and despite Adam's insurances)
urifixup code of the docshell is called (as it previously would have been to add
www. and/or .com) ... all \ are converted to / and the right host is called but
of course the document with a trailing / can not be found.

This is because we do not store the original url but try the fixup on the
already mangled (parsed) url.




To fix this in the long run I would propose the following:

There should be a wrapper around every call to an uri on a high level (like
loadURI). This wrapper should take in a uri-string (not an URI!!!!), maybe a
charset hint and some information on who is calling it (urlbar or link or
something else). This wrapper should be called every time a link is clicked or
something is put into the urlbar or any other case when there is a *string* that
is supposed to be an URI.

First thing should be a copy of the original string for future reference. Then
we should try to create the URI. If that works fine *and* the call returns no
error (like host unknown or page not found) the we are finished. If not, we
catch the error (without notifying the user), store it and should try different
fixups based on the information who is calling (for example: is there user
interaction?), prefs that call off any (or certain) fixup, ... and based on the
*original* uri string, for example changing \ to /.

If all that fails (and the caller implies user interaction) we should return an
error message to the user based on the *original* string and (maybe) the first
error we got.

How does that sound?

Comment 10

[Darin Fisher]

-> future

Comment 11

[Dan Star]

I think this bug relates to badly coded pages which there are many of (MS
conspiracy?).  This page http://www.rustoleum.com/ibg/MSDS/default.asp is
especially problematic and is important to for my company to access.  IE handles
switching \ and spaces on the PDF file references to / and %20%, but Moz only
fixes the spaces not the /.  I know that \ should be used in a file name but
MANY sites do this.  For now, I have to roll out IE to the affected users.  Oh
well...  More IE users.

Comment 12

[Dan Star]

Correction: I meant \ should not be used in a file name reference but is a lot.
 Not enough coffee yet...

Comment 13

[Andreas Otte]

Dan: Since converting \ to / breaks pages and violates RFCs I see no chance that
this conversion will come back. However with a rework of the fixup stuff which
first tries urls according to RFCs and then gradually tries different fixups it
might be possible.
Best way would be to evangelize the website to do the right thing, write the
webmaster about the problem.

Comment 14

[Hixie (not reading bugmail)]

(Note that \ is still changed to / if the URI is typed by hand, see bug 127831.)