should EventSource bypass service worker interception?

[wanderview]

Currently we support intercepting EventSource. I'm even adding a wpt test for this since its a way to observe a different FetchEvent.request.cache value.

While writing that test, though, it became apparent that EventSource is currently difficult to use with ServiceWorker. EventSource is designed with the idea that the connection will be held open and lines will be flushed across the connection to trigger events. This is quite difficult to do today with synthetic responses. It might be possible in the future with streams, but you would still have to hold the SW alive.

@sicking suggested that we might want to treat EventSource like WebSocket and just bypass the service worker for now.

I feel like this is kind of a low priority item, but wanted to file the issue so we don't lose track of it.

[annevk]

WebSocket is special in that it's an HTTP handshake and then uses the connection for something else. EventSource is just like any other API that fetches something, it's just by design a longer-lived transaction, but that is not too different from <video> or <audio> really.

[annevk]

Also, in the no-streams scenario the service worker would just return the response from the server directly and then the user agent can close the service worker, right? There's no need to wait for end-of-file unless the developer is trying to observe it. And again, that would be no different from other places that fetch.

[NekR]

Anne's explanation sounds right to me

[wanderview]

Yes, but I believe the browser will immediately trigger another connection unless you send evenetsource content providing a retry delay, etc. So in the naive case it will keep spinning up the service worker over and over again.

[annevk]

If the connection closes for some reason, sure. But that's not the common scenario and also does not seem like a good enough reason. It's still equivalent to all other things that fetch.

[wanderview]

Well, "closes for some reason" means passing anything to evt.respondWith() in a no-streams implementation. The network connection is considered closed immediately after processing that Response body which will be fixed length.

I'm fine continuing to intercept EventSource. To be honest, I doubt many people will ever run into this interaction. Its just a bit wonky to use with ServiceWorkers.

[annevk]

Passing a network response (whose body is streaming) to it should work, no?

[wanderview]

Right. It should.

I'll just close this for now.