301/302/303 Redirect does not preserve headers

[etinquis]

What is the issue with the Fetch Standard?

The Bun JS runtime (https://github.com/oven-sh/bun) has recently updated their fetch implementation to match this spec. This has broken my client code due to the removal of headers sent on the original request from the subsequent redirected request.

See the issue I logged against bun here: oven-sh/bun#6053.

They're pointing to this portion of the spec: https://fetch.spec.whatwg.org/#http-redirect-fetch, in particular #12 which states:

If one of the following is true

- internalResponse’s [status](https://fetch.spec.whatwg.org/#concept-response-status) is 301 or 302 and request’s [method](https://fetch.spec.whatwg.org/#concept-request-method) is `POST`

- internalResponse’s [status](https://fetch.spec.whatwg.org/#concept-response-status) is 303 and request’s [method](https://fetch.spec.whatwg.org/#concept-request-method) is not `GET` or `HEAD`

then:

- Set request’s [method](https://fetch.spec.whatwg.org/#concept-request-method) to `GET` and request’s [body](https://fetch.spec.whatwg.org/#concept-request-body) to null.

- [For each](https://infra.spec.whatwg.org/#list-iterate) headerName of [request-body-header name](https://fetch.spec.whatwg.org/#request-body-header-name), [delete](https://fetch.spec.whatwg.org/#concept-header-list-delete) headerName from request’s [header list](https://fetch.spec.whatwg.org/#concept-request-header-list).

Is this desired/expected behavior? If so, could you please explain why? Why would POSTs be singled out for 301s and 302s, and why would this not be the case for 303s?

My specific relevant case is a PUT, not a POST, but that's not necessarily a hard requirement if there's a way around this. How would I go about implementing an API that would have the semantics of a PUT/POST that redirects to a GET if I need headers passed to the resulting GET?

[etinquis]

Looking closer, is the issue a misinterpretation of request-body-header name? It appears that this is a strict set of headers:

A request-body-header name is a [header name](https://fetch.spec.whatwg.org/#header-name) that is a [byte-case-insensitive](https://infra.spec.whatwg.org/#byte-case-insensitive) match for one of:

`Content-Encoding`
`Content-Language`
`Content-Location`
`Content-Type`

and not all headers.

[annevk]

Yes, we strip a set of headers related to the request body. But not all headers. That's very much intentional as the request body isn't forwarded either in these cases (all of these go to GET which doesn't have a body).

[etinquis]

Thanks! It was acknowledged as an implementation bug, so no issue with the spec.

Still curious about the POST special case for 301 and 302s; is that just for legacy reasons?

[annevk]

Browsers convert POST to GET for those and have done so forever, yes. It's allowed by the HTTP RFC and it's why we have 307 and 308 now (they don't do that).