3 ms·

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 evide

by niftich 10y ago

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 https://news.ycombinator.com/item?id=12224258 [2] https://github.com/GoogleChrome/http2-push-manifest https://github.com/GoogleChrome/http2-push-manifest [3] https://blogs.akamai.com/2016/04/are-you-ready-for-http2-server-push.html https://blogs.akamai.com/2016/04/are-you-ready-for-http2-ser... [4] https://blog.cloudflare.com/announcing-support-for-http-2-server-push-2/ https://blog.cloudflare.com/announcing-support-for-http-2-se... [5] https://www.w3.org/TR/preload/#server-push-http-2 https://www.w3.org/TR/preload/#server-push-http-2 [6] https://caddyserver.com/blog/implementing-http2-isnt-trivial https://caddyserver.com/blog/implementing-http2-isnt-trivial

jimktrains2 10y ago
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)?
- danudey 10y ago
  Nothing that HTTP/1.1 and websockets can't do, really.
  - jimktrains2 10y ago
    Sure but then you have a websockets interface , is there something similar for http2 that breaks the resource requests-resource response model?
- jkarneges 10y ago
  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.
danudey 10y ago
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.

by niftich 10y ago

jimktrains2 10y ago

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

danudey 10y ago
Nothing that HTTP/1.1 and websockets can't do, really.
- jimktrains2 10y ago
  Sure but then you have a websockets interface , is there something similar for http2 that breaks the resource requests-resource response model?
jkarneges 10y ago
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.

danudey 10y ago

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.