Service workers and URL fragments

[annevk]

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.)

Tests:

• https://github.com/web-platform-tests/wpt/pull/9604 (landed)
• https://github.com/web-platform-tests/wpt/pull/12680 (under review, will need to be adjusted per any agreement reached)

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

[wanderview]

Just thinking this through out loud here....

I don't like status quo because it deviates from redirects.

I would be for alternative 2, except its a breaking a change. Fragments are exposed on FetchEvent.request.url today and its hard to know if there are service workers out there customizing logic based on the fragment.

I guess alternative 1 also has some backward incompatibility today. If there is an existing service worker that progressively caches responses it could stumble into the cache poisoning scenario you outline above.

The site could probably more easily fix alternative 1 issue than they could fix alternative 2, though. The site could just do new Response(response_with_fragment) when adding to cache_storage to avoid the poisoning. If their fetch handler logic depends on request fragments, though, that would require architectural changes to fix.

Of course, alternative 1 problem is much more likely than alternative 2.

From a launching perspective I think we could probably craft metrics to determine how often alternative 1 problem occurs. I'm not sure how to craft a metric to detect fragment-specific logic in alternative 2 problem, though.

We could try to measure how possible alternative 1 is before deciding. Measurements would require remembering the response fragment (even if not exposed yet) and then counting how many pages return a cache_storage originated response with a different fragment than FetchEvent.request.url.

If the measurements show the issue does not happen in practice today then I would argue to go ahead with alternative 1. If the issue is real, though, then maybe we could be default to not storing fragments in cache_storage and provide a preserveFragment:true option in cache_storage to opt in to storing it.

I think my main concern with this plan would be the cost of getting measurements in place and this not being a prioritized effort.

What do other folks think? @jakearchibald @asutherland @youennf @mfalken