Bug 258720

We are experiencing an issue in WebKit based browsers that occurs after several consecutive 303 redirects.

Starting from the second consecutive 303 redirect, the initial Content-Type header is applied to the request originating from that redirect. This seems to be the wrong behavior, as requests originating from a 303 redirect are GET requests, so they should not include a Content-Type header.

The following example illustrates the observed behavior:

POST request to https://example.com/1, Content-Type: application/x-www-form-urlencoded -> Header Location: https://example.com/2 (303) -> GET request to https://example.com/2, no Content-Type header -> Header Location: https://example.com/3 (303) -> GET request to https://example.com/3, Content-Type: application/x-www-form-urlencoded

In this case, the GET request to https://example.com/3 (which is triggered by the second 303 redirect) contains the header Content-Type: application/x-www-form-urlencoded. It seems that this header is taken from the initial POST request that started the chain of redirects. However, we would expect that this request does not contain a Content-Type header, as it is a GET request.

We have observed that the Content-Type header is not added if the second redirect has status code 302. In our understanding, the behavior for 303 redirects should not be different from 302 redirects in that case, however.

We have prepared a little demo, where the described flows can be reproduced. It is available at https://redirect.swi024.dev.cubera.ch/index.php .

It seems that this issue occurs in WKWebView & Safari starting from iOS 16.4, as well as Safari on macOS, probably also starting from Safari 16.4. Presumably, it has been introduced by this change: "Bug 242969 - We should maintain the original Content-Type header on 303 HTTP redirect" (and its PR https://github.com/WebKit/WebKit/pull/2602). There is also a corresponding note in the release notes of Safari 16.4: "Fixed maintaining the original Content-Type header on a 303 HTTP redirect.".

The observed behavior means that HTTP requests produced by following the second 303 redirect are invalid HTTP requests according to RFC 9110 which states that "A client SHOULD NOT generate content in a GET request [...]" (https://www.rfc-editor.org/rfc/rfc9110#section-9.3.1-6), i.e., the request should also not contain a Content-Type header.

This issue is critical, as those invalid HTTP requests might get (in certain cases already are) blocked by web application firewalls, breaking existing flows that worked before Safari 16.4.

Also, we could not observe this behavior in Blink and Gecko, i.e., no Content-Type headers are added there after the second consecutive 303 redirect.