Hacker News Reader

Comment by jimktrains2 | Hacker News Reader

With HTTP2, you're no longer limited to a request-response model. What interfaces do people use to expose this new paradigm to the application? (e.g. application-based push).

View on HN

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

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.

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.

grpc uses it for streaming. This means the if you use grpc for RPC, you are not limited to sending one request object and get one reply object but there can be a stream of request and reply objects in each direction. You can e.g. make things like server-sent-events or some websocket use-cases superfluos with that. E.g. you send an empty request body (headers contain the method you want to call) and get a stream of status updates (events, chat messages, ...) in the response stream.

However this is not something that is limited to HTTP/2. In principal you could do the same with HTTP/1 as the request and response bodies were also already streams. However there are some limitations to that: At first most HTTP/1 implementations do only allow a certain amount of parallel HTTP connections, which means long-running streams are not useful because they block off other requests. The second issue is that many HTTP library implementations (including XHR browser API and the current fetch API) do not allow to read the bodys in streaming form. This is also the blocker for having full grpc support in the browser. WIP browser APIs (fetch API with readable stream support) will allow to make use of these capabilities, for HTTP/2 and HTTP/1.

Reply on news.ycombinator.com