Comment by niftich | Hacker News Reader

Comment by niftich | Hacker News Reader

Parent Full thread

They usually don't, because server push is a micro-optimization, proper use of which requires a lot of effort from the server (and perhaps the client), as evident from Google's research on the matter [1].

Google has coded their App Engine to read a 'push manifest' generated by a tool they publish [2]. Akamai gives you a GUI [3]. Cloudflare wants you to manually set headers [4] defined by the brand-new W3C draft 'preload' [5]. Last year, the Caddy devs blogged that HTTP/2 Push is essentially a big exercise for the reader/implementer [6].

I'm currently unaware of any web application framework which exposes idiomatic hooks to use HTTP/2 to push additional resources to the server. There are some generic server push addons or plugins that use older techniques from the websocket or pre-websocket days.

[1] https://news.ycombinator.com/item?id=12224258

[2] https://github.com/GoogleChrome/http2-push-manifest

[3] https://blogs.akamai.com/2016/04/are-you-ready-for-http2-ser...

[4] https://blog.cloudflare.com/announcing-support-for-http-2-se...

[5] https://www.w3.org/TR/preload/#server-push-http-2

[6] https://caddyserver.com/blog/implementing-http2-isnt-trivial

Also server push ignores the client's cache, so it's not actually a good optimization unless they're things you know aren't in the cache or they're small enough that youi can re-send them every time.

Push was just an example. HTTP2 is fundamentally different from HTTP; it's more akin to TCP in L7. Can applications take advantage of this fundamental paradigm shift? What about for non-browser clients (api clients)?

Nothing that HTTP/1.1 and websockets can't do, really.

Sure but then you have a websockets interface , is there something similar for http2 that breaks the resource requests-resource response model?

Server push is pretty much the only real difference from an interface perspective. Otherwise HTTP/2 is semantically the same as HTTP/1.1, just with certain optimizations like header compression and multiplexing. I don't think we'll see many applications built on top of HTTP/2 libraries wanting to directly control that kind of plumbing.

Even server push can be abstracted away via a cache. Pushed resources fill the cache, and when the application tries to fetch those resources the underlying HTTP/2 library could return the cached resource. This should be quite interesting to API clients, so that services don't have to make aggregate resource endpoints just to avoid round trips.

I do think future applications will want to have code triggered when a pushed resource arrives, though. I'm not aware of anyone doing this but it could be an interesting alternative to long-polling or streaming. That said, long-polling and streaming become very attractive within HTTP/2 as well, so it'll be interesting to see what developers end up doing.

Reply on news.ycombinator.com