Closed Bug 309668 Opened 16 years ago Closed 6 years ago
Choosing last Location: header rather than first
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****
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.
Assignee: nobody → darin
Component: Location Bar and Autocomplete → Networking: HTTP
Product: Firefox → Core
QA Contact: location.bar → 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 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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.