SXG loading and service worker integration

[mfalken]

I'm raising this issue as suggested by horo at #347 (comment)

The current spec has an Overview which explains service worker integration. I'm wondering whether some alternatives were considered and rejected.

If navigationPreload is enabled, the signed response will be available in the FetchEvent's preloadResponse. Note that this will also cause a network request for requests that aren’t served from a signed exchange.

I think this makes sense. My understanding is that if the request were to go to "network" (i.e., the service worker doesn't call respondWith()), the response would come from the signed exchange, so preloadResponse should be that response.

clone() the request and set its cache to "only-if-cached", to retrieve the matching response from either the signed exchange or the HTTP cache. Note that fetch()ing a new Request with the same url will not retrieve the response from the signed exchange.

This I'm not sure about. Historically respondWIth(fetch(event.request)) is expected to have the same behavior as not calling respondWith(). Is it possible to arrange things such that fetch(event.request) gets the response from the signed exchange by default and you need to clone() request and set a flag to skip the signed exchange?

[mfalken]

One possibility (which @wanderview also mentions at w3c/resource-hints#78 (comment) for prefetch) could be to tie the signed exchange to the request's client, so that fetch(event.request) goes to the signed exchange by default, and you can construct a Request with a null window otherwise to disassociate from the signed exchange. Or introduce a similar property like signedExchange.

[wanderview]

Could we make Request cache value of "default" mean include checking the signed exchange by default and the "reload"/"nocache" would bypass it?

[jyasskin]

I intend that respondWith(fetch(event.request)) does have the same behavior as not-calling respondWith() since the stashed exchange is attached to the request, and even follows its clones. respondWith(fetch(event.request.url)) does not have the same behavior, since the new request created from a plain URL doesn't include the stashed exchange.

If there's something in the algorithms that contradicts this, let me know so I can correct it (or realize that my intent is wrong, which is always possible).

I think we talked about ways to make respondWith(fetch(event.request.url)) also use the signed exchange and decided it was too complicated, but I don't remember where those conversations happened aside from my quick sketch in #281 (comment).

[mfalken]

Thanks, that's good to know! Actually after writing that comment I saw the request's "signed exchange" defined and then wondered why it wouldn't be used but didn't want to triple post :)

I think the current Overview wording may be confusing... I'd suggest clarifying that respondWith(event.request) just works (it reads as if you must clone() and set the cache mode).

I think I can see why having the same behavior for respondWith(fetch(event.request.url)) would be difficult if the idea was that fetching https://publisher.example.org/ would normally not retrieve contents from the SXG while fetching it while inside the SW's fetch event during the SXG would. There's nothing tieing the SW or fetch event to the SXG, except the request's internal signed exchange, so having a new request skip the SXG sounds reasonable to me.

I'm also wondering now about the suggestion to set the cache mode to get the SXG content after cloning. Wouldn't just cloning without changing the cache mode work?

[jyasskin]

The overview says, "If [a Service Worker] needs to know that signed exchange content is available for the request it’s handling, it has two options:" before saying to use the cache mode, and I think you didn't read that before jumping to the text about respondWith(). Adding more words will not help with that problem.