Body should not be transmitted if service worker intercepts request

[jakearchibald]

https://fetch.spec.whatwg.org/#http-fetch 3.3.1 "Transmit body for request".

If the service worker has provided a response, it should have transmitted the body itself in a separate call to fetch, or transmitting is unnecessary since the SW provided a response from the cache API or similar.

[annevk]

cc @yutakahirano

So this relates to upload streams. Main question I guess is whether a stream gets drained if the service worker doesn't touch it? (If no, this means that a page can observe a service worker in a new way, maybe unexpected.)

[annevk]

cc @domenic

[wanderview]

Do we care about sites observing there is a service worker? We break that in other places.

For example, this code:

let response = await fetch(crossOriginURL, { mode: 'no-cors' });
let text = await response.text();

Without a service worker the response will always be opaque and the text will be empty string. A service worker can return a basic Response, though, and the spec currently says to expose that basic response to the outer page. So in that case the body could be observed. (There was a spec issue about this case, but I don't have it handy at the moment.)

[jakearchibald]

Seems fine that it's observable. Ideally it would cancel the body stream if it doesn't need it.

[annevk]

Yeah, I wonder how it works for responses created in a service worker today. Since that also somewhat depends on how we cross the boundaries between Document<>Fetch<>Service Worker<>Network.

[domenic]

I'm having a bit of trouble understanding that step (3.3.1) in the first place, but I think it is probably unnecessary, yeah... I mean, the body needs to get from the main thread to the service worker, but it sounds like that step is not how it happens? How does it happen?

[wanderview]

It effectively needs the transfer thing we've talked about for postMessage.

[annevk]

Before streams the way it happened is that requests and responses (as concepts) can just be transferred across threads. But JavaScript streams were never backed by internal streams so at that point that strategy started falling apart and we haven't really made an effort to patch it back together again.

[yutakahirano]

Sorry for the delay. Probably I added the sentence but it doesn't make sense at all. I'll create a PR which removes the item.

[annevk]

Note that just removing it doesn't really work either, since it results in XMLHttpRequest not getting the tasks queued that it needs for uploads. Unless I'm missing something.

[annevk]

So if we remove this line, XMLHttpRequest wouldn't see uploads if there was a service worker. Has anyone tested this?

[yutakahirano]

I haven't checked this but I don't think service worker provides fake upload progress in our implementation. @mfalken, do you know?

[yutakahirano]

Confirmed. No upload progress events are delivered on Chromium.

[yutakahirano]

#1144 is fixing this.