Re: [whatwg/fetch] Browsers preserve fragments on redirects (#505)

Your comment made me remember that response's URL (list) is just a copy of request's URL (list), and when it's not, it's null. So I think that means that in this case we can actually use the fragment from the base URL (the response's URL). Which means we don't have to pass an additional parameter to the location URL algorithm and that also means HTML does not need changes. And yes, it's ignored during parsing `Location`'s value, but [HTTP requires](https://httpwg.org/specs/rfc7231.html#header.location) that it's still used if the resulting location URL does not have a fragment. I think that settles it for redirects.

Now, Chrome/Safari do not have the same behavior as Firefox, see https://github.com/web-platform-tests/wpt/pull/27575. Firefox has the behavior I described for all redirects, but Chrome/Safari only do it for navigation. Per HTTP that is a bug and back in 2018 we reached agreement on aligning with HTTP.

I think for redirects that's the right approach and I will update the PR accordingly.

Now for service workers it's less clear. I agree that any caches should not store fragments and ignore them when they are used in a key. So if the service worker returns something from the Cache API it would always be equivalent to the responding with Fetch `y` scenario and never `y#y`. But when the service worker fetches itself and responds with that it's less clear to me. In particular because `y` wins over `x`. Although we do know that `#x` needs to win over nothing. So maybe we should treat the service worker as being able to supply us with responses and those responses keep their own URL identity, but only up to the fragment, which is always set by the request, be it to null or a string. (Which coincidentally would align with implementations today.)

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