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

Oh fun. I hadn't thought of that. I haven't had a chance to actually try it, but looking at the code, our current implementation is in this `ComputeRedirectInfo` function:
https://source.chromium.org/chromium/chromium/src/+/master:net/url_request/redirect_info.cc;l=137-149;drc=2ac64302ae161cd6b5e4b1254497bdf5fd6d3415;bpv=1;bpt=0

Which ends up copying the fragment from the request's URL *after* we've already resolved the location URL to `new_location`. That's called both in the net stack (where this isn't so messy) and when we follow a Service-Worker-provided fragment. So I think that means our current behavior is:

* Response URL's fragment is irrelevant. It is the base URL when resolving the location URL, but fragments of base URLs don't matter.
* If the result of `response_url.Resolve(location_header)` has no fragment and the request URL has a fragment, use the request URL's fragment.

If I understand you correctly, it sounds like Chrome and Firefox have the same behavior right now.

I suspect this behavior is the right one: consider any alternative where we used the response.url fragment (i.e. give back y#y). That would require the response URL preserve the fragment which, in turn, means `fetch("foo")` and `fetch("foo#bar")` give different responses. That would then mess up caching and probably is not what we want.

Though this does probably mean having to duplicate the fragment copying in HTTP-redirect fetch and navigation. (Or does it? Do fragments matter outside navigation?)

> Also note the comment that if response.url is changed to include the fragment then we would avoid overriding in that case. So the final example you have would become y#y instead.

I guess this is a question of whether you believe resolving the Location header against response.url runs the "parse URL" algorithm or "parse URL" followed by "copy over fragment for redirects". Relative URL resolution normally ignores the base URL's fragment.

-- 
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-777846470