Is respondWith(fetch(event.request)) always the same as not calling respondWith()?

[mfalken]

At the Loading Signed Exchanges spec, the service worker interaction is defined such that respondWith(fetch(event.request)) produces different behavior than not calling respondWith().

I'm know we've historically tried to keep this the same. Are there any other known cases where these differ?

I've also filed WICG/webpackage#409 for the specific issue of SXG and service worker interaction.

[annevk]

I'm pretty sure, e.g., request's destination is reset for one and not the other. And we don't do say CSP checks with the service worker's CSP when you don't call respondWith().

(Note that some of this does need to happen with routing.)

[asakusuma]

It would be really nice if they were the same, or if there was another way to "bail out" of responding once you've already passed a promise into respondWith.

[annevk]

@jakearchibald should we reconsider this yet again? I know we went over it a bunch of times in the past, but perhaps exposing something like defaultfetch() in service workers for this purpose makes sense?

[jakearchibald]

I'm half way through going through the signed exchange spec & plan to understand it by the end of the week. I'd still like to avoid defaultFetch() if we can.

TODO for me: list all the ways respondWith(fetch(event.request)) is different to no respondWith. Off the top of my head there's MIX, but I'm sure there's more.

[annevk]

CSP of the service worker will not apply, Sec-Fetch-* if added won't be changed, etc.

[mfalken]

I misread the Loading Signed Exchange spec and respondWith(fetch(event.request)) is expected to be the same as not calling respondWith(). What made me wary was WICG/webpackage#347 (comment) and being told the spec would have to change to keep the equivalence.