Comment by mbell | Hacker News Reader

Comment by mbell | Hacker News Reader

To explain the use case for this (as I understand it):

http/2 push sounds great at first glance for doing things like sending your CSS/JS bundles downstream with the HTML. The problem with this is that only the system that builds the HTML knows what needs to be pushed and only the system terminating the http/2 connection can send the assets. That means your app servers would need to terminate the http/2 connection and would be serving static assets. Serving static assets from your app server sucks for a lot of reasons. Instead what you want to do is tell some upstream proxy that is good at serving static assets what it should push. This is done by having the upstream proxy parse the Link HTTP headers in the response, which many services already do. But, today they can't start pushing assets until the main response is being sent since they need the headers from it to instruct them. Ideally you'd start sending assets ASAP, while the app server is building the page. This is exactly what the 103 response is most useful for.

e.g. You have a CDN front for your app servers, the app server sends an early 103 as soon as it knows what assets the page needs, the CDN intercepts this response and uses it to start pushing the assets to the client from the local edge node using http/2 push. This lets you benefit from http/2 push of your assets while processing the main response without your app server needing to serve static assets or even know about http/2 itself.

Does HTTP2 support multiple concurrent streams over a single client connection? If not, presumably your use case would require that the client has a separate HTTP2 connection opened up to the CDN already, right? Or am I missing something?

In my example there would be only a single connection from the client, to the CDN edge. The CDN is acting as a reverse proxy for the main request and pulling Link headers out of the response(s) to decide what static assets to push to the client over the same connection.

I don't love the idea of routing all my app traffic through the CDN edge, and I really get the willies thinking about terminating app-tier SSL at the CDN. I guess if a deployment is all-AWS or something, sure, but there's plenty of static content that I'm comfortable sharing with my CDN even though I don't want them seeing any user-generated content or metadata.

Yes HTTP2 supports Multiplexing: http://qnimate.com/what-is-multiplexing-in-http2/

While I disagree with mbell's interpretation of the value of this header or how it could be used, to answer you're question pcl, yes HTTP 2 does support multiple streams over a single transport connection.

To me, I would say increasing efficiency (or decreasing latency) was a central design goal of HTTP2. So HTTP2 includes it's own framing, which allows multiplexing across the connection. This helps avoid the overhead of establishing multiple parallel connections to speed up page load, head of line blocking, running slow start on each connection, etc.

> While I disagree with mbell's interpretation of the value of this header or how it could be used

FWIW the use case I'm describing has already been added to Rails / Puma:

http://eileencodes.com/posts/http2-early-hints/

https://github.com/rails/rails/pull/30744

https://github.com/puma/puma/pull/1403

Sorry, I apologize for being unclear, I don't agree with you're interpretation of the use case that adds the most value.

While the RFC does state that what you described can happen at a caching intermediary, I don't believe that's where the value lies or the primary use case. To me, much of the value added is to get the 103 to the client early, and allow it to begin making decisions on whether the content is in it's local cache, or to begin making requests to third party servers.

This helps eliminate some of the weaknesses with HTTP push, mainly being that only content the server is authoritative for can be pushed, and that the server doesn't know whether the resource to be pushed already exists in a client cache.

It's a balancing act of course, but if the resource being pushed is above a certain size, pushing the resource on each request could add overhead, not reduce it.

The problem is that clients won't be supporting 103 for a long time, I would guess it'll be 3-5 years before you can realistically push the 103 to a browser and I don't thank any currently support it. It's also not a particularly safe thing to turn on. e.g. Chrome prior to 57 bombed on http/2 connections that sent a 103 which is in contrast to the RFP's theory that http/2 clients should be 'safer' in handling it than http/1 clients. We really don't know how many clients and proxies will have trouble with 103 and have to wait for the vast majority to at least ignore it / pass it along before it could be turned on externally.

> This helps eliminate some of the weaknesses with HTTP push, mainly being that only content the server is authoritative for can be pushed, and that the server doesn't know whether the resource to be pushed already exists in a client cache.

When a server sends a push to the client it first sends `PUSH_PROMISE` command to the client and the client may cancel the push, e.g. if it already has the asset in cache based on url. Assuming things move forward the server sends a HEADERS frame which can also trigger to the client to cancel the push, e.g. in response to an etag, though at this point some DATA frames may be in flight.

You are correct that you can't push assets for another domain, but I don't see this as much of a problem as there are many other benefits to having all requests go a CDN/reverse proxy that can handle the static asset serving, like regional SSL termination. There are of course third party scripts that may be needed, but it's good practice make these non-blocking for page rendering anyway so if they are a bit behind that is probably ok, if not preferable.

Reply on news.ycombinator.com