Re: [whatwg/fetch] Propagate URL fragments (#696)

@davidben commented on this pull request.



> @@ -3835,6 +3836,13 @@ these steps:
       </ul>
 
       <p>then return a <a>network error</a>.
+
+     <li>
+      <p>Set <var>actualResponse</var>'s <a for=response>URL</a>'s <a for=url>fragment</a> to
+      <var>request</var>'s <a for=request>current URL</a>'s <a for=url>fragment</a>.
+
+      <p class=note>There is currently no mechanism for the service worker to control
+      <var>actualResponse</var>'s <a for=response>URL</a>'s <a for=url>fragment</a>.

If I'm understanding this right, it means:

* If a SW-less document contains `<img src="redirect.py?url=colors.svg%23green#red">`, we'll render `colors.svg#green`, since the location URL algorithm prefers the `Location` header's fragment.
* If that same document has a service worker which simply does `ev.respondWith(fetch(ev.request))`, the FetchEvent will be resolved with a Response containing `colors.svg#green` (since redirects were followed), but then this logic will replace the fragment with `#red`.

Am I understanding this right? Is that intentional?

That seems kinda weird, though I don't see clear alternatives given service worker caches should not be sensitive to fragments, and service workers take over URLs. One possibility, which is janky in a different way (but has a nice symmetry with redirects in general), would be to say:

* When a SW gets a FetchEvent, remove the fragment from the request URL. The SW, like an HTTP intermediary, should not get to react differently on request fragments.
* The response URL preserves the fragment. But, due to step 1, any fragments would come from redirects or the service worker itself. We haven't yet incorporated the request fragment.
* When we consume a SW-forwarded response, apply the request fragment similar to redirects: if the response URL had a fragment, use that. If not, use the request fragment.

(By the way, are there subresource contexts other than SVGs where the fragments matter?)

-- 
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/pull/696#pullrequestreview-592609922