3 ms·

Honestly curious: how would you use HTTP{2,3} to push a real-time message from server to client without a WebSocket? Are we back to just long polling?

• Matthias247 8y ago
  You can use server-sent-events or use do some custom streaming format inside the response body. The latter might not work well, due to the fact that arbitrary streaming APIs might not yet be exposed by all browsers (ReadableStream on fetch API: https://caniuse.com/#feat=streams https://caniuse.com/#feat=streams).
  • cryptonector 8y ago
    I thought all XHRs support streaming, and they should run over HTTP/{2,3}. Is that not right?
    • Matthias247 8y ago
      Afaik XHR allows you to access received data in a streaming fashion, but the XHR type will always buffer the full received payload internally. So if you try to stream a large amount of data over it you will eventually run out of memory. If you want to consume a potentially endless stream with custom encoding you need the fetch API with streaming support for that (https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Using_readable_streams#Consuming_a_fetch_as_a_stream https://developer.mozilla.org/en-US/docs/Web/API/Streams_API...), as far as I understood. Or websockets. That is one reason that e.g. gRPC streaming support doesn't work trivially in browsers.
• jungturk 8y ago
  Server-sent events (SSE) is an option. https://blog.sessionstack.com/how-javascript-works-deep-dive-into-websockets-and-http-2-with-sse-how-to-pick-the-right-path-584e6b8e3bf7 https://blog.sessionstack.com/how-javascript-works-deep-dive...
• jrockway 8y ago
  gRPC is already HTTP/2.0 and has bidirectional streams. I imagine it would work like that. Browsers are almost at the point where they can just talk gRPC to the backend, but gRPC uses HTTP trailers which browsers do not support. I don't think, from a networking standpoint, that websockets was really necessary. A browser and a web server already have a socket open that they send messages in either direction on. It's just so much of the web was designed around "client asks for something, server sends the result and closes the connection" that some transition period was necessary to distinguish between the two cases. (You didn't necessarily provision your web server for maintaining hundreds of thousands of open connections.) But now that people are used to the idea of connections sticking around in the context of HTTP, it's no big deal to send arbitrary data over that connection.
  • icebraining 8y ago
    But can the client in HTTP/2 send more data to the server after it has received something, without having to send a full HTTP request? If not, I don't see how something like agar.io, which requires constant updates to the server on every mouse movement, can work without tremendous header overhead.
  • gizzlon 8y ago
    Not really, it's rpc and websocket is not. I looked into this for a project and neither http/2 or gRPC does the same thing : fully bidirectional, long-lived stream with no weird semantics or hacks.
• seabrookmx 8y ago
  Exactly. I think most people didn't use Websockets due to the theoretical performance improvement over HTTP 1.1, but because it's a different programming model. I think it's very shortsighted to assume people should (or want) to roll their own streaming protocol when Websocket is already a great fit for many applications.