@slightlyoff can you please take a look and let me know if that looks reasonable to merge?

LGTM, assuming @slightlyoff is happy with it

/cc @annevk @jakearchibald.. fyi. let me know if you have any feedback on this one.

I'm not sure this is needed. Feels like this spec should detail how https://fetch.spec.whatwg.org/ should be invoked, then you get all the ServiceWorker stuff for free. I guess it could just point to the relevant part of the html spec (which would be different for each as value).

That would cover all the edge cases, eg:

<link rel="prefetch" as="object" href="…">

…shouldn't go through the SW at all as it's a potential client request.

<link rel="prefetch" as="worker" href="…">

…should go through the SW that matches its URL, since it's a client request.

I'm not sure this is needed. Feels like this spec should detail how https://fetch.spec.whatwg.org/ should be invoked, then you get all the ServiceWorker stuff for free.

@jakearchibald where does Fetch explain which SW-registration the request is routed to? FWIW, based on a lengthy conversation with folks working on this (crbug.com/465200 captures the summary), this behavior is not obvious and needs to be explicitly documented.. where that lives I'm not picky on.

Re, worker/object: interesting... You should followup on the crbug to make sure that doesn't get lost. /cc @KenjiBaheux

Step 2 of HTTP fetch hands off to Handle fetch in the SW spec. Steps 12 & 13 handle registration selection.

Yeah, this should just fall out from how you invoke Fetch (not necessarily fetch(), that's just an API).

At some point all specifications in the platform will be updated to invoke Fetch. And then how CSP, Mixed Content, Service Workers, Referrer Policy, X-Content-Type-Options, etc. work will fall out naturally.

@jakearchibald @annevk trying to parse out the steps here...

12.3 Set registration to the result of running Match Service Worker Registration algorithm, or its equivalent, passing r's url attribute value as the argument.

So, say I have example.com that has a prefetch for bar.com/foo.. Wouldn't the above result in handing off the prefetch request to bar.com's SW registration? Whereas, we want it to be seen by example.com?

That's step 12.2, no? Why would "prefetch" qualify as a client request? I don't think it would.

Yeah, 12 differentiates between client & resource requests. So as=worker would go through 12.x, whereas as=image would go through 13.x

@annevk @jakearchibald ah, ok, I think I'm with you guys now..

• Preconnect doesn't invoke fetch, so that's moot.
• Prefetch is classified as "resource request" and is handled by client's active worker.
• Prerender... should be classified as a client request. I think this needs to be added to SW spec?

With that, I think all the rights bits are in place.. I'd just need to clarify the connection to Fetch in RH -- if you have suggestions for where/how, lmk.

Prerender is definitely a client request, but I wonder if there's a hook into the document loading parts of the html spec for that?

Prefetch/preload is either a resource request, a client request, or potential client request depending on the "as" attribute. "worker" is client, "image" is resource, "object" is potential client.

Prerender is definitely a client request, but I wonder if there's a hook into the document loading parts of the html spec for that?

The Fetch spec is very particular about definition of client request: https://fetch.spec.whatwg.org/#client-request - it seems that we need to have prerender on that list regardless.

Prefetch/preload is either a resource request, a client request, or potential client request depending on the "as" attribute. "worker" is client, "image" is resource, "object" is potential client.

Sanity check.. Assuming we have <link rel=prefetch as=import...>, when the request lands in SW, what does it report as its context? Will it be set to "prefetch", or will it be set as "import"? If it's the former then all prefetch/preload initiated requests are client-requests.. which, I don't think is entirely unreasonable.

It must be the latter. Take as=iframe, if you load that as a resource, then add an iframe to the page with the same url, either you ignore the prefetched response, or you use it and have an xss vulnerability.

Hmm, ok. So, to close the loop on this particular pull.. what are our resolutions?

• It sounds like I can close it, as the logic is handled in Fetch and SW specs. However..
• Fetch spec should add "prerender" to definitino of "client request"? Service Worker interop #30 (comment).
• The interop with as and where request gets routed probably deserves a mention somewhere.. perhaps as an implementation concern note in RH spec? I'd like to surface this, as I don't think its obvious.

Added "prerender". If "as" becomes a thing separate from "context" we need to update Fetch to support it... Probably best to do that via a new ticket in the Fetch repository.

@annevk perfect, thank you!

Closing this and opened a new bug to track the "implementation consideration" stuff (#31).