167858 - treat 404 as file not found, guess again

Status: RESOLVED DUPLICATE of bug 482874

(Core :: DOM: Navigation, enhancement)

Description

[timeless]

I've asked and it seems that the http spec does not forbid us from treating 404
as 'file not found, guess again'. if we did that, then we could have at least
the following hueristics:
index.html => index.htm => ./
index.htm => index.html => ./
\ => /

why should we do this? 
* it solves the silly \ / issue. We sometimes display pretty errors instead of
the server generated 404 anyway, so here we'd just be displaying pretty content.
* it solves the .html/.htm issue (it's not an issue, but it's a cute feature)

how should this work? if a guess succeeds, the jsconsole should get an error
like we do for text/css explaining that we tried BAR got ERROR FOO and then
selected BAZ.

for \ => /, we have a bit of freedom
case: http://silly/resource\case\annoying\file
proposed sequence:
GET  http://silly/resource\case\annoying\file => 404
HEAD http://silly/resource\case\annoying/ => 404
HEAD http://silly/resource\case/ => 404
HEAD http://silly/resource/ => !404
HEAD http://silly/resource/case\annoying/ => !404
GET  http://silly/resource\case\annoying/file => !404 => done :)

this can fail in lots of ways, and is expensive, but it'd be loads of fun :-)

this feature should have a hidden pref, and will probably be on for netscape and
off for mozilla:europe. (it could be on for mozilla:us, but i'm not going to
cast a vote on that.)

Comment 1

[Susie Wyshak]

Good idea. This also *should* be on for embedded clients and needs to be a very
helpful/end user friendly message that gives reasons why the page may not have
been found.

As noted in bug 16728 Microsoft Word uses \ for hyperlinks to files and so this
could be a very prolific problem. I will evangelize them but this is important.

Comment 2

[Bradley Baetz (:bbaetz)]

We can't use HEAD, since some servers (ie Netscape server version *mumble*) will
give a 404 to a HEAD for a directory reqponse.

More importantly, this isn't our job.

.html<->.htm _definately_ isn't something we should be doing, though - does IE
do that????

For / vs \, I can sort of see the argument (which I personally disagree with,
mind you...), but it should be an all or nothing job, rather than try 2^n
combinations

Actually, I have a better idea. Lets just not encode the \ as %5C. Won't IIS
then do the translation on the server side? Anyone got packettraces from IE?

As for moz:us vs moz:europe, this stuff should not be geographically based....

Comment 3

[Dave Barrowman]

Stupid question on '/' vs '\': what does IE do?  

Comment 4

[Alex Bishop]

> Stupid question on '/' vs '\': what does IE do?  

If you type http:\\www.mozilla.org\projects\embedding\MRE.html into IE, it will
load the correct page as if you had typed
http://www.mozilla.org/projects/embedding/MRE.html. Though this is handy, the
behaviour is incorrect because while
http:\\www.mozilla.org\projects\embedding\MRE.html isn't a valid URL, I believe
that http:\\www.mozilla.org\projects/embedding/MRE.html potentially could be.

Comment 5

[Bradley Baetz (:bbaetz)]

So it changes the slashes always, unconditionally? Thats just so broken....

I think your last example was meant to be
http://www.mozilla.org/projects\embedding\MRE.html though - ie you got the
slashes back to front.

Note that IIS swaps \ to / - http://www.microsoft.com/windowsxp\pro\ loads in
mozilla w/o problems. This is probably correct, since the paths /windowsxp/pro
and /windowsxp\pro are treated identically on windows. ie this is only an issue
for non-win32 servers (not sure if apache::win32 does the same thing as IIS,
mind you)

Comment 6

[Hixie (not reading bugmail)]

We already have a bug about mangling \ and / when the URI is typed in. If we do
it, we should definitely only do it on a 404 (we currently do it the moment the
user hits enter on the location bar). See:
   http://www.hixie.ch/tests/adhoc/uri/backslash\001.html

Comment 7

[Alex Bishop]

> So it changes the slashes always, unconditionally? Thats just so broken....

I think so. A few days ago I came across a page that demonstrated this (it had a
link to something like http://www.example.net/some\url\path.html - any IE users
following the link would end up at http://www.example.net/some/url/path.html)
but I can't locate it right now.

> I think your last example was meant to be
> http://www.mozilla.org/projects\embedding\MRE.html though - ie you got the
> slashes back to front.

Yeah, you're right. I confused myself! :-)

Comment 8

[Alex Bishop]

> We already have a bug about mangling \ and / when the URI is typed in. If we do
> it, we should definitely only do it on a 404 (we currently do it the moment the
> user hits enter on the location bar). See:
>    http://www.hixie.ch/tests/adhoc/uri/backslash\001.html

Mozilla seems to get it wrong if you open the link in a new tab too. IE seems to
get it wrong in all cases. Additionally, it leaves the URL in the Address Bar as
http://www.hixie.ch/tests/adhoc/uri/backslash\001.html so that's doubly wrong.

Comment 9

[Bradley Baetz (:bbaetz)]

mozilla has a whole set of uri fixiups which only apply to the url bar,
scattered throughout the code (mainly in docshell, IIRC) Almost all of these
fixes apply to urls which would otherwise be invalid (and there are several bugs
on those which apply everywhere).

Note that its not incorrect to do exactly what the user typed/the page said. Its
a QoI issue to try to fix it if what they did wasn't valid, though.

Re comment 7, my point was: 'if you use \ in a url, and you have a file on a
server with \ in it, does ie correctly open the file' ? Thats the case which we
want to get right...

Comment 10

[Hixie (not reading bugmail)]

IE always mishandles a backslash except when it is explicitly escaped in a link.

Comment 11

[Andreas Otte]

I have to agree with timeless, having something like this guessing mechanism
would be cute and I have proposed it myself from time to time. I think it will
be a major redesign of the fixup code, the urlparser and code that loads urls.

1. remove all fixup code from the urlparser. Make it really stupid and unforgiving.
2. remove all current urifixup code from docshell.
3. have a new fixup layer between urlbar/pages and necko that, based on which
part of the code is calling it, the scheme, and perhaps the platform, trys with
some heuristics different versions of an url if the original one fails. In case
everything fails return the original url with the original error.
4. Have all url load code use the new layer.

For example there should be more heuristics in place when the url comes from the
urlbar instead of a page. Or the should be more fixup for windows. Also having
all fixup in one place would allow for easy configuration (on/off/different levels).

confirming ... :)

should be moved to docshell I think

Comment 12

[Boris 'pi' Piwinger]

I fully agree with Bradley (comment 2), this isn't our job.

If I type in a URL, I want to see exactly this URL's result. This might be a bit
nerdish, but I always hate being redirected to special 404 pages on different
servers or paths (which is of course broken on that server's configuration), so
I cannot easily correct my typo, this would also be the result of the original
suggestion. I hate software which "knows" better what I want than myself. This
is like the spell checker in MS Word. IOW: Don't fix it if it ain't broken.

We see how bad this I-know-it-better-than-the-user-approach is in IE. Why do
people have pages using \ instead of /? Because IE will display it. Don't let
Mozilla become part of the problem.

pi

Comment 13

[Alex Bishop]

> Re comment 7, my point was: 'if you use \ in a url, and you have a file on a
> server with \ in it, does ie correctly open the file' ?

No. IE always gets it wrong, unless, as Hixie says, the '\' character is escaped
(so while http://www.hixie.ch/tests/adhoc/uri/backslash\001.html won't work,
http://www.hixie.ch/tests/adhoc/uri/backslash%5c001.html will).

Comment 14

[Darin Fisher]

-> docshell (URI fixup)

Comment 15

[Boris Zbarsky [:bzbarsky]]

Probably a dup of cbartley's work.