Closed Bug 309668 Opened 16 years ago Closed 6 years ago

Choosing last Location: header rather than first


(Core :: Networking, defect)

Windows XP
Not set





(Reporter: ninodelsol, Unassigned)




(Keywords: helpwanted)

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 
That URL contains a typo that initially alerted me to the 404 handling bug
2. try accessing
3. try accessing

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

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

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


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 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****
wget -S
 5 Location:
 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.
Assignee: nobody → darin
Component: Location Bar and Autocomplete → Networking: HTTP
Product: Firefox → Core
QA Contact: → networking.http
Version: unspecified → Trunk
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.
The competition is choosing the first one, not just the best: in which is just doing

header("HTTP/1.1 302 Found");

both IE and Opera choose m.o, only we choose, 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.
Summary: some erroneous URL requests forwarded you to NASA site instead of giving 404 error → Choosing last Location: header rather than first
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?
Severity: normal → minor
Ever confirmed: true
Keywords: helpwanted
Target Milestone: --- → Future
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking
Target Milestone: Future → ---
for smuggling reasons we only allow 1 value of location header without throwing an error
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.