57529 - Incorrect base url for HTTP error 401 error document

Status: VERIFIED INVALID

(Core :: Networking: HTTP, defect, P3)

Description

[Florian Effenberger]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
BuildID:    2000031000

Hi,

I am sorry, but I just found that out in Netscape 4.73, don't know if Mozilla 
has it, too.

I created two .htaccess files on my server. One resides in the root directory 
(/) and has the ErrorDocument directive:

ErrorDocument 401 /error_401.html

In the error_401.html file, there is an image embedded with relative adressing 
(IMG SRC="image.jpg"), as it resides in the same directory.

In a directory called /web/mysubsite/ I have another .htaccess files which sets 
the user authentification. When I fail the user authentification, Internet 
Explorer 5.5 shows my error file, including the image correctly. Netscape 4.73 
thinks the image file is also in /web/mysubsite/, which is WRONG. So he cannot 
load it and asks me for authentification again.

To put it in a nutshell:
IE thinks, the file is in www.mydomain.com/image.jpg, which is right
NS thinks, the file is in www.mydomain.com/mysubsite/image.jpg whis is WRONG

Reproducible: Always
Steps to Reproduce:
1.-
2.
3.

Comment 1

[Mitchell Stoltz (not reading bugmail)]

Reporter, does Mozilla exhibit this behavior or not? Please let us know.
Reassigning to Networking, but this is obviously still UNCONFIRMED.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I see this on linux trunk 2000110908.

Specifically, go to http://www.zbarsky.org/moztest/index.html
Pick "Cancel" from the dialog.  See there be no image.

If you want to see what the error document should look like, just go to
http://www.zbarsky.org/moztest (no trailing slash).  Then Mozilla thinks the
base URL is http://www.zbarsky.org/ and loads the image correctly in the error
document.

Confirming and OS -> All.
Changing summary to make it more meaningful.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I've looked into this some more, and I am not sure it's valid...  When the
server I have returns the 401 (Auth required) response, it includes the html for
the error ducument in the response.  Thus there is no way to know what directory
the document is actually being fetched from.

Reporter, could you post a URL for an access-restricted directory on your
server?  If we could see what accessing that actually returns, it would help
immensely in resolving this bug.

Thank you, and my apologies for the spam...

Comment 4

[Darin Fisher]

->me

Comment 5

[Bartosz Wucke]

I think this appears in all such "error" pages, like 404 and so on - they have
no clearly defined root. With 401 the problem is simply that worse that not only
the document, but the whole directory is obviously unavailable.

Testcase for 404 version: 
Try these documents: 
http://wolf.solutions.net.pl/nonexistent
http://wolf.solutions.net.pl/subdir/nonexistent
http://wolf.solutions.net.pl/far/nonexistent (but that's httpd vulnerablity)
http://wolf.solutions.net.pl/~spamlista/nonexistent
http://wolf.solutions.net.pl/none/nonexistent

The last one is a neat example - the browser looks for all the images inside of
a directory that doesn't exist.

(expected results: the image 
http://wolf.solutions.net.pl/home.png
appears in all above cases.)

I've been looking for standards concerning the error pages, but was unsuccessful
at that. It looks for me like this matter hasn't been regulated. Obviously, the
behavior described as "expected results" would be more desirable, but also
obviously, whoever uses relative URLs in documents without real root, is asking
for trouble.

Removing "verifyme", I think that's documented well enough for now. If you think
otherwise, put that back.
Also suggesting renaming the bug to cover the whole family of problems 
("incorrect base url for HTTP error documents")

Comment 6

[Yves Lambert]

http://www.viewline.net/ 
Mozilla doesn't acknowledge login information request by the ASP and this
generate a 401.2 error instead of 401.1
-> i submit a new bug. mark it as DUPEME. mark it as blocking this Bug 134103
and bug 12578 
sorry for the spam.

Comment 7

[benc]

Doesn't the root remain whatever comes from the requested URL?

It seems like that would be the apparent value unless a BASE was sent back in
the response...

Comment 8

[benc]

darin: bz says I should get your permission to invalidate this bug.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Er, what I actually said was that I can't tell whether this is valid, but that
darin would likely be able to....

Comment 10

[Boris Zbarsky [:bzbarsky]]

The basic question is this "Should we treat error page as if their URI is the
document root, no matter what we were fetching?"

It seems to me that that is sub-optimal, since it removes the ability to
actually have the error pages refer to content in the same dir as what you were
trying to fetch (which gives greater flexibility).

Further, the HTTP spec does not make error pages special in any way here that I
can see -- if I ask for a URI and get an error page, that URI _is_ the URI of
that error page.

So invalid.

Comment 11

[benc]

VERIFIED: invalid.
I'm w/ bz here. If you want your error.jpg's to come from a specific place, you
should have absolute paths or URLs, not relative references.

Florian: how would IE know what the root is? is there a base= tag we are ignoring?