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

@annevk I'm not sure I understand the claim that Fetch can replace WebSocket. I Googled around a bit and couldn't find anything explaining how this could be done, so I hope you don't mind if I ask here.

Are you suggesting that people can replace a WebSocket with a single "full-duplex" HTTP request, relying on the ability to start reading the response while still sending the request body?

If that is what you mean, that could work over HTTP/2 but lots of HTTP/1 infrastructure is not designed to support bidirectional streaming (even though the protocol technically doesn't prevent it). Can/should apps be probing somehow to see if they have HTTP/2 all the way back to the origin server? In a world with proxies, CDNs, load balancers, etc., it's pretty common to have requests that bounce between protocol versions as they traverse the network, so this seems error-prone.

Or are you instead suggesting that apps should use old-fashion long polling patterns, while sending upstream messages as separate requests? This is problematic in use cases where the client and server want to maintain some shared state connected to the WebSocket. When polyfilling WebSocket using long polling, you end up needing to configure load balancers to support "sticky sessions" (so that messages intended for the same virtual-WebSocket land at the same server), which is tricky at best and often not supported at all.

On another note, does fetch streaming guarantee that HTTP chunk boundaries on the wire will be preserved through to Javascript? Or would the application need to provide its own framing? WebSocket's built-in framing is nice to have, though admittedly not that hard to implement manually.

-- 
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-300258124