Re: [w3c/ServiceWorker] Should EventSource and WebSocket be exposed in service workers? (#947)

> I guess so, just like they'd have to do with WebSocket today. But it should work with HTTP/1 too, in theory.

Hmm, I would be pretty concerned that this is the kind of thing that will regularly and unexpectedly break.

Proxies have a lot of legitimate reasons for breaking full-duplex streaming. For example, nginx likes to buffer request bodies to disk in order to protect backends from slow-loris attacks and in order to avoid excessive memory buffering. But this feature assumes half-duplex (response-strictly-follows-request) operation.

I worry that even with HTTP/2 (and especially with HTTP/1), we're going to see trouble with infrastructure (proxies, CDNs, load-balancers, etc.) that assume half-duplex because "it seemed to work" and the developers didn't know better. These assumptions may even appear unexpectedly in production, when the CDN added a new "feature" or the load balancer admin changed a setting that looked harmless.

Thus it seems pretty risky for applications ever to rely on this.

The nice thing about WebSocket is that it's very explicitly intended to be full-duplex, which makes it much less likely that anyone would break it by accident.

Of course, these are human bugs, not spec bugs.

> Chunked is only applicable to HTTP/1 and if you use it via the mechanism defined in HTTP it will end up decoded by the time the data reaches JavaScript.

Sorry, that's not quite what I was asking. What I was asking was, if the server sends two chunks (or HTTP/2 frames), will the client be guaranteed to receive two callbacks from a ReadableStream, or might it only receive one callback in which the chunks are concatenated? I'm assuming the latter, hence the application must define its own framing on top.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/947#issuecomment-300272644