This is pretty funny. After all the fuss, turns out that server push isn't really useful. I'm half impressed that they are able to actually admit they were wrong (implicitly of course) by removing it. I can't say I'm surprised, either. I could never think of a reasonable use case for it.
With the variety of streaming options available now, it really seems antiquated.
It's currently in Last Call, but if there's consensus to modify HTTP/3 that can be done at any point, although obviously doing it after it's actually published would be in the form of errata or a -bis RFC that modifies the standard. It's not extraordinary for something which has consensus to get done really late, even in AUTH48 (a notional "48 hours" for the authors of the document to fix any last little things that often lasts rather longer than two Earth days) if that's what people decide is necessary.
But "Blink doesn't want to do it" isn't consensus on its own, this page suggests other clients implement this and offers no opinion about whether they intend to likewise deprecate the feature.
This 100%. There is so much confusion between HTTP/2 Push and and HTTP/2 bidirectional streaming capabilities, I personally had to go back to the Spec. to understand the difference because a lot of material just mixes them together. They are not the same thing.
Websockets are different again from both server push and h2 streams. Server push was a feature added in http2 for populating the browser’s cache. Websockets are an http/1.1 extension for tcp-like bidirectional messaging.
Server push, websockets, h2 steams and webtransport are all different things.
Yea but unlike http2 push, server sent events were actually useful! You could use it super easily and by holding open a connection and pushing down little json or XML payloads you could build all sorts of things easily in JavaScript. I even saw super basic chat functionally built using two Iframes a form in one and the chat log pushed back from the server as a stream of valid but open ended HTML abusing how lax the browser was about parsing missing certain closing tags at the time. SSE was and still is super easy to use and a very useful option if you can’t or don’t want to shift to web sockets.
SSE can be polyfilled to work in IE11. It can be implemented on top of XHR from ie7 or so onwards.
Some caching proxies struggle with it though, because they try to buffer an entire response before forwarding it. And it’s 1 way. For something like collaborative editing, crafting a POST request for every keystroke feels wasteful, though it works great in practice.
I use the heck out of SSE to add update notifications to various of my apps because it's just so easy to do. Have it glued to a Redis stream (or pubsub channel) with https://github.com/bonkabonka/sseredis (though that shim looks like it needs a bit of love and a better README.)
With the variety of streaming options available now, it really seems antiquated.