[whatwg/fetch] Service workers and URL fragments (#1175)

#505 and #696 have unearthed that dealing with URL fragments correctly for service workers is rather tricky so I'm splitting that out into this issue. This is tracked on the service worker side in https://github.com/w3c/ServiceWorker/issues/1564.

There's a couple of options from those discussion threads I'll try to summarize, but ideally @davidben and @wanderview would come to some agreement here I think as Chrome would need to experiment with changes to the status quo:

* Status quo (roughly): a service worker response cannot impact the resulting fragment. The document request fragment (whether null or non-null) wins.
* Alternative 1: responses store the final fragment. This leads to cache pollution problems. If document 1 fetches `x#foo` and that gets cached, document 2 fetching `x#bar` would still end up with `x#foo`. This does not seem acceptable to me, but @wanderview is still in favor of it I think.
* Alternative 2: service workers do not get a document request fragment, but if they end up with fragment on their own (through a service worker request or redirect), it is stored. So similar to alternative 1, without the cache pollution problem. (See https://github.com/whatwg/fetch/pull/696#discussion_r577929526 for the longer version.)
* Alternative 3: responses have an additional field that stores where the fragment originates from. When caching you would only store fragments obtained through redirects. (See https://github.com/whatwg/fetch/pull/696#discussion_r578543960 for the longer version and possible 3a/3b alternatives.)

See also #1167 (for exposing fragments on responses).

-- 
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/1175