Re: [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)

As summarized in the issue description, the only response caching that the Fetch spec defines is defined as occurring prior to HTTP-redirect fetch being run.

And Ladybird doesn’t implement any caching of its own separate from what the Fetch spec defines.

I guess other UAs do some other caching of their own outside of what the Fetch spec defines, and they do it after HTTP-redirect fetch is run. And that’s fine, because I guess any UA is free to do HTTP response caching whenever and wherever they want — and because other UA’s HTTP caching behavior was implemented long before they implemented Fetch.

But the Fetch spec doesn’t define anything about how HTTP caching should work after is HTTP-redirect fetch being run. Instead the spec only defines HTTP caching _prior_ to HTTP-redirect fetch being run.

And Ladybird has never had any HTTP caching implemented separate from the the Fetch spec requires — instead, Ladybird strictly implements only what the Fetch spec explicitly requires, and exactly in the order the spec requires it.

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

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