5 ms·

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 wron

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.

stock_toaster 6y ago
It's too bad they didn't realize it sooner, or it could have been removed from HTTP/3 before IETF finalizes it. Probably too late now?
- tialaramex 6y ago
  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.
gravypod 6y ago
Server push is quite useful for bidirectional streaming of data which is heavily used in gRPC to help reduce latency and shovel large amounts of data.
- Guthur 6y ago
  And the problem there is shoe horning RPC requirements into a hypermedia transport. I feel we've made a big mistake following Google's micro service requirements for what should be a ubiquitous hypermedia back bone. It's bewildering that so many smart people could end up conflating the two for our standard protocols.
- ahupp 6y ago
  I think this is different than server push like WebSockets; this is all about pushing down resources the server suspects you'll need.
  - josephg 6y ago
    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.
    - brabel 6y ago
      Don't forget Server Sent Events[1] as well, which is yet another different technology. [1] https://en.wikipedia.org/wiki/Server-sent_events https://en.wikipedia.org/wiki/Server-sent_events
      - techdragon 6y ago
        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.
        earthboundkid 6y ago
        Most applications that use WebSockets should be using SSE instead, but WS has better mindshare, and SSE doesn't work in IE11.
        josephg 6y ago
- psanford 6y ago
  gRPC does not use PUSH_PROMISE. It uses HTTP/2 streams, but those streams all get initiated by the client.
  - pa7x1 6y ago
    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.
baybal2 6y ago
I will be very sceptical about all "real world usage" statistic claims from Google.
- d2wa 6y ago
  They’re one of very few companies in the world that are in the position to actually measure this.
youngtaff 6y ago
Even before HTTP/2 was standardised there were some strong arguments by Mike Belshe (co-creater of SPDY) and others that we should drop push But it never happened and so made it into the H2 standard

stock_toaster 6y ago

It's too bad they didn't realize it sooner, or it could have been removed from HTTP/3 before IETF finalizes it. Probably too late now?

tialaramex 6y ago
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.

gravypod 6y ago

Server push is quite useful for bidirectional streaming of data which is heavily used in gRPC to help reduce latency and shovel large amounts of data.

Guthur 6y ago
And the problem there is shoe horning RPC requirements into a hypermedia transport. I feel we've made a big mistake following Google's micro service requirements for what should be a ubiquitous hypermedia back bone. It's bewildering that so many smart people could end up conflating the two for our standard protocols.
ahupp 6y ago
I think this is different than server push like WebSockets; this is all about pushing down resources the server suspects you'll need.
- josephg 6y ago
  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.
  - brabel 6y ago
    Don't forget Server Sent Events[1] as well, which is yet another different technology. [1] https://en.wikipedia.org/wiki/Server-sent_events https://en.wikipedia.org/wiki/Server-sent_events
    - techdragon 6y ago
      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.
      - earthboundkid 6y ago
        Most applications that use WebSockets should be using SSE instead, but WS has better mindshare, and SSE doesn't work in IE11.
        josephg 6y ago
psanford 6y ago
gRPC does not use PUSH_PROMISE. It uses HTTP/2 streams, but those streams all get initiated by the client.
- pa7x1 6y ago
  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.

baybal2 6y ago

I will be very sceptical about all "real world usage" statistic claims from Google.

d2wa 6y ago
They’re one of very few companies in the world that are in the position to actually measure this.

youngtaff 6y ago

Even before HTTP/2 was standardised there were some strong arguments by Mike Belshe (co-creater of SPDY) and others that we should drop push But it never happened and so made it into the H2 standard