Spec review

I've been going through the spec to review its service worker interactions. Here are the questions/thoughts I had along the way:

Note that fetch()ing a new Request with the same url will not retrieve the response from the signed exchange.

I don't think fetch(event.request) will get the signed exchange either right now. Calling fetch(request) calls new Request(request) internally, so https://fetch.spec.whatwg.org/#dom-request will need to be modified to preserve the stashed exchange.

https://wicg.github.io/webpackage/loading.html#mp-http-fetch - I think these steps will be invoked twice if there's a service worker in the middle.

1. Resource requested.
2. Ask service worker for response.
   1. Service worker calls fetch(event.request).
   2. Response is an SXG, so the steps in https://wicg.github.io/webpackage/loading.html#mp-http-fetch happen.
   3. Redirect mode is "manual", so the redirect response is returned from the service worker.
3. Response is an SXG, so the steps in https://wicg.github.io/webpackage/loading.html#mp-http-fetch happen.

This seems wrong when it comes to reporting, but maybe also bad that the SXG is parsed twice.

Set actualResponse’s status to 303.

If the request was a POST request, what's the expected behaviour here? 303s will typically drop the request body from the redirected request.

Should I be able to add a signed exchanged into the cache API? Right now it looks like a fetch to an SXG would create and follow the redirect, and I'd get the other-origin response rather than the SXG itself. Should the processing of SXG responses be limited to navigations?

If response is null and httpRequest’s initiator is "prefetch" or "preload", return a network error.

Is it odd that this happens with "prefetch" and "preload" only? Should it happen with fetch('whatever.sxg') too?

Start with the linked loading specification's mp-http-fetch section and the Fetch specification's Request constructor, then trace the service-worker fetch flow, redirect handling, cache behavior, and prefetch/preload branches described here. Done means the open questions have agreed expected behavior and corresponding spec changes are identified.