3 ms·

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) y

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.

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.