1614151 - Firefox shouldn't redirect to location on HTTP 300

Status: RESOLVED DUPLICATE of bug 1854695

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

Description

[Radosław Piliszek]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

Visit a URL which returns HTTP 300 with a location OR use the fetch API on such a URL.

This also affects ESR 68.
Also note Chrome and now Edge do not follow location on 300 (also node.js as far as fetch is concerned).
I marked this as a RFE because all mentioned platforms really follow the standard which says:
"If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise. "
But it would be beneficial if all browsers followed the same behavior for compatibility. I am especially worried about fetch since I've already spent quite a time to discover what Firefox is doing differently than other platforms for a simple API call.

Actual results:

Firefox redirects to location.

Expected results:

Firefox returns original response.

Comment 1

[Dragana Damjanovic [:dragana]]

The "Location" header holds the server's preferred choice.
I am actually fine with what our implementation is doing. I think this response code is not really wide spread because the spec is not well define.
We could try to measure how often this response code is used.

Comment 2

[jannis]

This now seems to be specified in the fetch specification and could be upgraded to a bug: https://fetch.spec.whatwg.org/#statuses
"A redirect status is a status that is 301, 302, 303, 307, or 308." In my understanding all other status codes should never redirect.

Comment 4

[Daniel Veditz [:dveditz]]

If Fetch intends to override HTTP semantics I'd want to see something stronger than assuming from omission. If the unmentioned codes aren't redirects then what are they?

HTTP Semantics RFC 9110 15.4. Redirection 3xx

If a Location header field (Section 10.2.2) is provided, the user agent MAY automatically redirect its request to the URI referenced by the Location field value, even if the specific status code is not understood.

15.4.1. 300 Multiple Choices

If the server has a preferred choice, the server SHOULD generate a Location header field containing a preferred choice's URI reference. The user agent MAY use the Location field value for automatic redirection.

Comment 5

[Daniel Veditz [:dveditz]]

I'm not saying Chrome and Safari are wrong. If Firefox "MAY" then other browsers are not required to make the same choice. The "parity-" keywords are not appropriate: this is maybe a webcompat issue, not a missing feature we need to catch up.

Comment 6

[Daniel Veditz [:dveditz]]

Supporting jannis' comment 2, the relevant part of the Fetch spec is 4.3 HTTP fetch.

6. If internalResponse’s status is a redirect status:
   [do redirect stuff]
7. Return response.

where a "redirect status" is one of the ones jannis mentioned, that is, excluding status 300. The Fetch spec also has explicit handling of 304 Not Modified elsewhere in the standard.

Comment 7

[jannis]

From my understanding Fetch "overrides" other specifications such as RFC 9110 in case they do not align.

I agree that this should be done more explicit:

• both that in general Fetch is what browser (should) implement and is overriding other specifications (opened an issue about that here: https://github.com/whatwg/fetch/issues/1700)
• and that 2.2.3 should be more explicit about what other status codes are/how they are handled. E.g., status code 401 and 407 have some special handling in 4.5 but are not mentioned at all in 2.2.3

Comment 8

[Thomas Wisniewski [:twisniewski][PTO until Mar.16]]

Was this not fixed with bug 1854695? (Shipping since Firefox 125).

Comment 9

[jannis]

Yes, it seems like this was fixed with https://bugzilla.mozilla.org/show_bug.cgi?id=1854695