309668 - Choosing last Location: header rather than first

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[TP]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 (ax)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 (ax)

The failure to recognize (or at least properly interpret and react to) the 404
header response does not happen with *every* domain, but it does happen *all*
the time with the some domains.  This goes for both Firefox 1.0.6 and 1.0.7.

Accessing the same URL using Microsoft IE 6 CORRECTLY gives you a 404 error if
you try to access an invented directory or filename.



Reproducible: Sometimes

Steps to Reproduce:
*Intentionally* generate a 404 error - use either Firefox 1.06 or 1.07:

1. access http://www.dow.com/polyclycols/ 
That URL contains a typo that initially alerted me to the 404 handling bug
2. try accessing http://www.dow.com/anyrandomdirectorynameyouinvent/
3. try accessing http://www.dow.com/anyrandomfilenameyouinvent.html

Literally invent whatever you want for steps 2 and 3.  Again, you are
intentionally trying to get a 404 error from the Dow.com server.
Actual Results:  
you get forwarded to:

http://www.nasa.gov/externalflash/screenreader/screenreader.html

Expected Results:  
Generated a 404 error.  The intentionally incorrect URLs in the Steps to
Reproduce (or any random dow.com URL you can think of to intentionally invoke a
404 error in the browser) should give you this page:

http://www.dow.com/homepage/404page.htm?404=anyrandomURLyouinventfordow_com

with that 404 variable indicating whatever you erroneously enters as the URL.



NOTES:

1. Tested repeatedly on multiple computers, in different geographic regions,
with/without routers or firewalls, etc. and Firefox consistently send you to the
NASA site instead of giving a 404 error for Dow.com pages.  This suggests that
it's not likely a DNS issue.

2. ****multiple builds of Microsoft IE 6 CORRECTLY gives you a 404 error if you
try to access an invented directory or filename on Dow.com****

Comment 1

[Phil Ringnalda (:philor)]

wget -S http://www.dow.com/anyrandomdirectory/
...
 5 Location:
http://www.dow.com/homepage/404page.htm?404=http://www.dow.com/anyrandomdirectory/&ref=
 6 Location: http:///homepage/404page.htm

which would make it a candidate for Tech Evangelism, except that both IE and
Opera deal with it by either choosing the one that resolves, or choosing the
first (have to test to see which), while we choose the second. If we're doing
that for a reason, I can't find a bug on it.

Comment 2

[Josh Birnbaum]

Multiple 'Location:' lines violate the RFC (quoted below).  I wasn't able to
find any other bug reports on this issue, though I recall a similar one with
multiple meta refresh's.  FWIW

RFC 2616 section 4.2:
[...]
   Multiple message-header fields with the same field-name MAY be
   present in a message if and only if the entire field-value for that
   header field is defined as a comma-separated list [i.e., #(values)].
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma. The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.

Comment 3

[Phil Ringnalda (:philor)]

The competition is choosing the first one, not just the best: in
http://philringnalda.com/mtests/headers/ which is just doing

<?php
header("HTTP/1.1 302 Found");
header("Location: http://www.mozilla.org/",false);
header("Location: http://www.opera.com/",false);
exit;
?>

both IE and Opera choose m.o, only we choose opera.com, and with the first one
as a broken URL instead, they both fail. Unless we have some reason to choose
the last instead, seems like we would be better off switching.

Comment 4

[Darin Fisher]

If the server wants to give multiple Location headers, then it should be using a
300 response code.  That said, I can see why it would be better to choose only
one of the Location header values to follow, and it probably makes sense to do
what IE does.  How common is this problem?

Comment 5

[Darin Fisher]

-> default owner

Comment 6

[Patrick McManus [:mcmanus]]

for smuggling reasons we only allow 1 value of location header without throwing an error