demo · v135
What happens to your headers on a 303 redirect
The interop bug from the Fetch spec the change resolves: when the server responded 303 (or any redirect that causes the method to flip from POST to GET), older Chrome kept body-related headers like Content-Type and Content-Length. Other browsers stripped them. The table below traces a sample request through both the pre-135 and post-135 paths so you can see which headers survive each redirect.
aligned with Fetch spec in Chrome 135
POST /upload → 303 redirect → GET /done
| request header | pre-135 | Chrome 135+ |
|---|---|---|
| Authorization | kept | kept |
| Cookie | kept | kept |
| Content-Type | kept | stripped (method changed) |
| Content-Length | kept | stripped (method changed) |
| Content-Encoding | kept | stripped (method changed) |
| Content-Language | kept | stripped (method changed) |
| request body | kept (illegal — GET has no body) | stripped |
| Referrer-Policy | preserved naively | re-evaluated against destination |
POST /api/x → 307 redirect → POST /api/x-renamed
| request header | pre-135 | Chrome 135+ |
|---|---|---|
| Content-Type | kept | kept (method unchanged) |
| request body | kept | kept |
see also
scenario focus
Select a scenario to focus its rendered example and summary.