5 ms·

I was surprised when I read that Server Push wasn't intended for event sourcing. Anyone know why? These days people use Server Sent Events and WebSockets for t

I was surprised when I read that Server Push wasn't intended for event sourcing. Anyone know why? These days people use Server Sent Events and WebSockets for this: The client requests data from the server (possibly through a "subscription" type of request), and the server keeps sending messages (e.g. chat messages) until the client cancels the request or closes the connection. Not having looked deeply into Server Push, it sounds ideal for this sort of thing, and then we could do away with both SSE and WebSockets, neither of which are very HTTP-y.

EGreg 10y ago
Why would you do away with them just because they aren't HTTP-y?
HorizonXP 10y ago
Confusing name but different use cases. HTTP/2 does introduce efficiency gains that will benefit SSE, but it's unlikely to supplant WebSockets entirely. https://www.infoq.com/articles/websocket-and-http2-coexist https://www.infoq.com/articles/websocket-and-http2-coexist
jaffathecake 10y ago
SSE is just a long-running connection, so it fits with HTTP/2 pretty well (and HTTP/1 for that matter). H2 push needs to be linked to an initial response, and I don't think it's acceptable to push resources once the initial response is complete. Also, H2 push is pretty much a request/response pair, so it can be cached, so it doesn't really fit the SSE model. You're right about websockets though. At some point they'll be replaced with something more H2-like, but it won't be push-based.
- dullgiulio 10y ago
  If the next protocol iteration is something like QUIC, then the WS could just be implemented over QUIC UDP packets.
- derefr 10y ago
  Right; Server Push isn't "send the client arbitrary data"; Server Push is "move link/subresource prefetch logic to the server, where you can take advantage of optimizations like single JOIN-queries that give you all you need to output multiple resources, actually outputting multiple responses."
vfaronov 10y ago
Server push sends responses to requests, only these requests are “promised” by the server. So, for every event pushed, the server would have to send at least three frames: promise (the synthesized request), response headers, and response data. Also, you would still need something else for HTTP/1.x. Even an HTTP/2 client does not have to support server push, and can even ask the server to disable it. Why do you think server-sent events are not HTTP-y? I found them as elegant as modern Web technology gets.
dsign 10y ago
SSE is not extremely HTTP-y but it at the core is the sort of thing we have used for ages for the same thing we use web sockets. The only difference between SSE and old good polling is the presence of a nice API on the browser side. We have worked with SSE, HTTP/2 and HTTP/2 Push of SSE event streams and it is a combination made in heaven. In particular, we use SSE events to have the server announce to the browser when a particular segment of an interlaced or progressive image has been delivered. With this combo, the SSE events can be delivered on the wire very close to the data frames for the image pieces themselves.
- derefr 10y ago
  > HTTP/2 Push of SSE event streams That's... brilliant, actually! It's like making a request in Go, and being returned a response promise, along with an "events that occurred during response processing" channel, which you can select() on until the promise is resolved.
manigandham 10y ago
WebSockets aren't perfect but they're a lightweight full-duplex protocol that is great for many real-time scenarios. Not being the same as HTTP is the point.
hdhzy 10y ago
FWIW there is an old spec draft for WebSockets over HTTP/2: https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01 https://tools.ietf.org/html/draft-hirano-httpbis-websocket-o...
- niftich 10y ago
  See the related curl blog post 'No websockets over HTTP/2' [1], which talks about that spec and how it didn't generate enough interest from concerned parties, and goes into some alternatives and perspectives on the matter. [1] https://daniel.haxx.se/blog/2016/06/15/no-websockets-over-http2/ https://daniel.haxx.se/blog/2016/06/15/no-websockets-over-ht...
  - hdhzy 10y ago
    Good post. > Sticking to HTTP/2 pretty much allows you to go back and use the long-polling tricks of the past before websockets was created. Interesting how things turned out. The old bad way is now a good way. Last time I've checked Google Hangouts also used polling instead of WebSockets.
nitwit005 10y ago
The fetch API is probably the closest to what you're asking for, as it allows for streaming a response, but is basically a plain HTTP request.

EGreg 10y ago

Why would you do away with them just because they aren't HTTP-y?

HorizonXP 10y ago

Confusing name but different use cases. HTTP/2 does introduce efficiency gains that will benefit SSE, but it's unlikely to supplant WebSockets entirely. https://www.infoq.com/articles/websocket-and-http2-coexist https://www.infoq.com/articles/websocket-and-http2-coexist

jaffathecake 10y ago

SSE is just a long-running connection, so it fits with HTTP/2 pretty well (and HTTP/1 for that matter). H2 push needs to be linked to an initial response, and I don't think it's acceptable to push resources once the initial response is complete. Also, H2 push is pretty much a request/response pair, so it can be cached, so it doesn't really fit the SSE model. You're right about websockets though. At some point they'll be replaced with something more H2-like, but it won't be push-based.

dullgiulio 10y ago
If the next protocol iteration is something like QUIC, then the WS could just be implemented over QUIC UDP packets.
derefr 10y ago
Right; Server Push isn't "send the client arbitrary data"; Server Push is "move link/subresource prefetch logic to the server, where you can take advantage of optimizations like single JOIN-queries that give you all you need to output multiple resources, actually outputting multiple responses."

vfaronov 10y ago

Server push sends responses to requests, only these requests are “promised” by the server. So, for every event pushed, the server would have to send at least three frames: promise (the synthesized request), response headers, and response data. Also, you would still need something else for HTTP/1.x. Even an HTTP/2 client does not have to support server push, and can even ask the server to disable it. Why do you think server-sent events are not HTTP-y? I found them as elegant as modern Web technology gets.

dsign 10y ago

SSE is not extremely HTTP-y but it at the core is the sort of thing we have used for ages for the same thing we use web sockets. The only difference between SSE and old good polling is the presence of a nice API on the browser side. We have worked with SSE, HTTP/2 and HTTP/2 Push of SSE event streams and it is a combination made in heaven. In particular, we use SSE events to have the server announce to the browser when a particular segment of an interlaced or progressive image has been delivered. With this combo, the SSE events can be delivered on the wire very close to the data frames for the image pieces themselves.

derefr 10y ago
> HTTP/2 Push of SSE event streams That's... brilliant, actually! It's like making a request in Go, and being returned a response promise, along with an "events that occurred during response processing" channel, which you can select() on until the promise is resolved.

manigandham 10y ago

WebSockets aren't perfect but they're a lightweight full-duplex protocol that is great for many real-time scenarios. Not being the same as HTTP is the point.

hdhzy 10y ago

FWIW there is an old spec draft for WebSockets over HTTP/2: https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01 https://tools.ietf.org/html/draft-hirano-httpbis-websocket-o...

niftich 10y ago
See the related curl blog post 'No websockets over HTTP/2' [1], which talks about that spec and how it didn't generate enough interest from concerned parties, and goes into some alternatives and perspectives on the matter. [1] https://daniel.haxx.se/blog/2016/06/15/no-websockets-over-http2/ https://daniel.haxx.se/blog/2016/06/15/no-websockets-over-ht...
- hdhzy 10y ago
  Good post. > Sticking to HTTP/2 pretty much allows you to go back and use the long-polling tricks of the past before websockets was created. Interesting how things turned out. The old bad way is now a good way. Last time I've checked Google Hangouts also used polling instead of WebSockets.

nitwit005 10y ago

The fetch API is probably the closest to what you're asking for, as it allows for streaming a response, but is basically a plain HTTP request.