3 ms·

No mention of what browsers do for notifications, Web Push Protocl[1]. Which makes sense only in the context of the one of the ancient grand-daddy issues of Fet

No mention of what browsers do for notifications, Web Push Protocl[1]. Which makes sense only in the context of the one of the ancient grand-daddy issues of Fetch being completely ignored by the powers that be[2], & the browser & the browser alone (not the page) having the capability to hear & observe HTTP2+ PUSH requests coming in. This github issue to let a fetch request hear PUSH responses come back at it has been mostly ignored, for 3/4 a decade. Meanwhile Chrome is saying people don't use Push. Yeah, well, because ye jerknuts have diluted & made unusable the best part of it: the ability to be responsive to resources coming at us. What a sad truckload of tragedy this undelivered capability has been. To invent a new HTTP, HTTP2, with new capabilities, then spend most of a decade ignoring & denying developers access to the best parts of what you just invented. Irony & tragedy. Now they're taking away PUSH[3], having never made it usable at all. Classic frigging Google, what frigging fickle monsters, incapable of even the most basic follow-through on what they start. [1] https://datatracker.ietf.org/doc/html/rfc8030 https://datatracker.ietf.org/doc/html/rfc8030 [2] https://github.com/whatwg/fetch/issues/51 https://github.com/whatwg/fetch/issues/51 [3] https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/vOWBKZGoAQAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYL...

chrismorgan 5y ago
I think you may be misunderstanding the purpose of RFC 8030, or if you do understand it (and after more careful contemplation of your wording, I think you do) you’re conflating two different things. It’s not something for web pages to implement or use, but for user agents to implement, providing a standard way of delivering events fielded via the Push API (which is for web content to use, and works well), because browsers were all implementing their own stuff for that, making interoperability or hosting your own push service (which is on the public internet and receives events and then sends them to the browser somehow) difficult. This happens to use HTTP/2 PUSH_PROMISE frames, and it’s a good use of them. But that doesn’t imply anything about exposing HTTP/2 Server Push to arbitrary web content. (I have no idea of the implementation status of RFC 8030, whether any or all user agents have replaced their own ad hoc systems with it.) The fact of the matter is that HTTP/2 Server Push really just didn’t pan out for general web content: its original intended purpose flopped, turning out to cause more trouble than it solves; cache digests could make this probably not so, but they make it even more complex, and add a little overhead, so that based on what’s been seen so far, implementer consensus (consensus, not just Google) is that it’s just not worth trying. Sad but true. As for the remaining possible cases, they’re served about as well and more compatibly by older techniques. (And compatibility is important: you emphatically cannot depend on HTTP/2 working, so you mustn’t require HTTP/2 features, so there’s not a great deal of purpose in implementing them at all.) So in the end, exposing HTTP/2 Server Push to client code is probably a net loss, significant complexity spent for significant risks, insignificant uptake, and negligible concrete benefits. Google is bad, sure, but I don’t think this is an example of that.
- rektide 5y ago
  > As for the remaining possible cases, they’re served about as well and more compatibly by older techniques. Noteably none of the alternatives deal directly in HTTP resources. HTTP PUSH could have/should have allowed sending new http resources directly. HTTP could have become a way to allow a page to be reactive, as new content was streamed at it, and this would have been a near ideal fit architecturally, building on what the web is and what http is, to meet with modern apps which have incoming new data streamed to them all the time. Instead we have this long list of un-HTTP non-resourceful hacks, to have a separate eventing system. Because HTTP2 built the tech then failed to let the page use it. Technology like RFC 8030 demonstrate what that better future look like & is widely used, just, as you say, not by the page directly. This is a fuck up, a huge missed opportunity. I disagree with your assessment that backwards compatibility means we should stick to the same ratty old non-resourceful options we've been stuck with: we should & ought to use better. That good tech was impossible to use directly by the page was a sin that prevented this technology from receiving adoption & attention. It feels like everyone is fixated on the cache-digest problem, which indeed is hard, but it's just not relevant. There's so many other interesting & good architectural options that this tech opened up. Just, the web never empowered developers to use them.

chrismorgan 5y ago

I think you may be misunderstanding the purpose of RFC 8030, or if you do understand it (and after more careful contemplation of your wording, I think you do) you’re conflating two different things. It’s not something for web pages to implement or use, but for user agents to implement, providing a standard way of delivering events fielded via the Push API (which is for web content to use, and works well), because browsers were all implementing their own stuff for that, making interoperability or hosting your own push service (which is on the public internet and receives events and then sends them to the browser somehow) difficult. This happens to use HTTP/2 PUSH_PROMISE frames, and it’s a good use of them. But that doesn’t imply anything about exposing HTTP/2 Server Push to arbitrary web content. (I have no idea of the implementation status of RFC 8030, whether any or all user agents have replaced their own ad hoc systems with it.) The fact of the matter is that HTTP/2 Server Push really just didn’t pan out for general web content: its original intended purpose flopped, turning out to cause more trouble than it solves; cache digests could make this probably not so, but they make it even more complex, and add a little overhead, so that based on what’s been seen so far, implementer consensus (consensus, not just Google) is that it’s just not worth trying. Sad but true. As for the remaining possible cases, they’re served about as well and more compatibly by older techniques. (And compatibility is important: you emphatically cannot depend on HTTP/2 working, so you mustn’t require HTTP/2 features, so there’s not a great deal of purpose in implementing them at all.) So in the end, exposing HTTP/2 Server Push to client code is probably a net loss, significant complexity spent for significant risks, insignificant uptake, and negligible concrete benefits. Google is bad, sure, but I don’t think this is an example of that.

rektide 5y ago
> As for the remaining possible cases, they’re served about as well and more compatibly by older techniques. Noteably none of the alternatives deal directly in HTTP resources. HTTP PUSH could have/should have allowed sending new http resources directly. HTTP could have become a way to allow a page to be reactive, as new content was streamed at it, and this would have been a near ideal fit architecturally, building on what the web is and what http is, to meet with modern apps which have incoming new data streamed to them all the time. Instead we have this long list of un-HTTP non-resourceful hacks, to have a separate eventing system. Because HTTP2 built the tech then failed to let the page use it. Technology like RFC 8030 demonstrate what that better future look like & is widely used, just, as you say, not by the page directly. This is a fuck up, a huge missed opportunity. I disagree with your assessment that backwards compatibility means we should stick to the same ratty old non-resourceful options we've been stuck with: we should & ought to use better. That good tech was impossible to use directly by the page was a sin that prevented this technology from receiving adoption & attention. It feels like everyone is fixated on the cache-digest problem, which indeed is hard, but it's just not relevant. There's so many other interesting & good architectural options that this tech opened up. Just, the web never empowered developers to use them.