[whatwg/fetch] Spec unexpectedly requires caching 30x responses themselves — rather than caching the result of running HTTP-redirect fetch to follow the 30x redirects (Issue #1765)

### What is the issue with the Fetch Standard?

The HTTP fetch algorithm at https://fetch.spec.whatwg.org/#ref-for-concept-http-network-or-cache-fetch says:
> Set _response_ and _internalResponse_ to the result of running [HTTP-network-or-cache fetch](https://fetch.spec.whatwg.org/#concept-http-network-or-cache-fetch) given _fetchParams_

.…where [HTTP-network-or-cache fetch](https://fetch.spec.whatwg.org/#concept-http-network-or-cache-fetch) ends up doing https://fetch.spec.whatwg.org/#ref-for-response.cacheability, which says:

> Store _httpRequest_ and _forwardResponse_ in _httpCache_, as per the "[Storing Responses in Caches](https://httpwg.org/specs/rfc9111.html#response.cacheability)" chapter of HTTP Caching. [[HTTP-CACHING]](https://fetch.spec.whatwg.org/#biblio-http-caching)

But, that happens _before_ a _later_ HTTP fetch step at https://fetch.spec.whatwg.org/#ref-for-redirect-status②, that says:

> If _internalResponse_’s [status](https://fetch.spec.whatwg.org/#concept-response-status) is a [redirect status](https://fetch.spec.whatwg.org/#redirect-status):… Set _response_ to the result of running [HTTP-redirect fetch](https://fetch.spec.whatwg.org/#concept-http-redirect-fetch) given _fetchParams_ and _response_.

So the effect of that seems to be that the spec unexpectedly requires caching 30x responses themselves — rather than caching the result of running HTTP-redirect fetch to follow the 30x redirects.

The Fetch implementation in Ladybird very closely follows the spec, and the result seems to the bug reported at https://github.com/LadybirdBrowser/ladybird/issues/863, which causes the 30x responses themselves to get cached.

And the workaround that’s been implemented in Ladybird for now was to add some ad-hoc non-spec-conforming code for special-casing 30x responses so that they don’t get cached where the Fetch spec currently seems to require them to be.

Anyway, as far as I can see, no other existing UAs actually implement the caching requirements for 30x responses in the current spec as currently written — because if other UAs did, then it seems like the observable behavior in those UAs would be what can be observed in Ladybird (without the https://github.com/LadybirdBrowser/ladybird/issues/863 workaround).


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1765
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1765@github.com>