Hacker News Reader

Comment by strommen | Hacker News Reader

I'm reasonably up-to-date on HTTP/2, but there are a couple issues with request multiplexing and server push that I'm confused about:

- When the browser requests a page, and the server wants to push the CSS, JS, etc. along with it, what happens if the CSS/JS is cached already on the client?

- Additionally, how does a server like nginx know what to "push"? Are servers expected to parse the script and link tags from the outgoing html? Or is this controlled by the application (and if so, how)?

View on HN

- The client can stop an incoming push (send reset on the pushed stream). Due to latency it might waste some bandwidth, but it's deemed to be an insignificant problem, since otherwise nothing else would be using the connection anyway.

- It's independent of the protocol. Each server can invent its own method. Personally I'm hoping servers/proxies will "upgrade" some HTTP/1.1 Link header to PUSH, e.g.:

    Link: </style.css>; rel=preload

> Due to latency it might waste some bandwidth, but it's deemed to be an insignificant problem, since otherwise nothing else would be using the connection anyway

That sounds like it could be an issue on mobile devices. If I've got a 1GB data plan, I don't want you sending large files that I've already got cached. Even partially sending them could consume significant bandwidth given the latency involved.

HTTP/2's flow control offers a bit of a solution here for mobile devices. Flow control operates on a credits/tokens scheme at both the connection level and the stream level. A mobile client could use a low initial window size so that all new streams are limited in how much data they can send. The client can preemptively grant large flow control windows to streams that it requests, and retroactively grant additional credits to push streams that it decides it wants.

The tradeoff is that you're introducing a round-trip for pushed resources to acknowledge that you want to receive the entire resource. That may or may not make sense, depending on the use case.

http://http2.github.io/http2-spec/#FlowControl

Okay, thanks. It looks like nghttp2 uses the Link header[1] as you suggest, and mod_spdy uses a "X-Associated-Content" header[2].

My biggest concern with HTTP/2 is that it's going to be difficult for web applications to organize their server push requests. It seems like it will definitely require updates to server app frameworks to make this tractable.

1. https://nghttp2.org/blog/2015/02/10/nghttp2-dot-org-enabled-... 2. https://code.google.com/p/mod-spdy/wiki/OptimizingForSpdy

> but it's deemed to be an insignificant problem, since otherwise nothing else would be using the connection anyway.

Except for other applications trying to use the finite, and possibly expensive, bandwidth of the connection as a whole?

As I've heard it explained, the server will push what it thinks is relevant [1] and if the resource is already cached in the client, the client will ask the server to stop the push.

The relevant mechanism seems to be described here: https://http2.github.io/http2-spec/#PushResponses

[1]: By some criteria. I don't have details here.

That's my understanding as well, but it's pretty fuzzy. How does the client stop the push, and what are the performance implications of this? Pages currently include dozens of external resources, and this will get worse if developers stop using bundles and sprites (because in theory HTTP/2 makes them pointless).

They send RST_STREAM, which can be done as soon as PUSH_PROMISE is received (which SHOULD [RFC2119] be sent before any data).

As I understand it, the more latent the connection the worse the behaviour (i.e., the more likely you are to receive too much data you don't need).

Maybe the browser can send a header "Cache-Control: allowpush" that tells the server that the site is not in cache. The server can then push everything. I can't see how server push is useful without client cooperation, unless the resource changes dynamically.

If-Modified-Since would already do that. But how does the client know that page B that it never requested has all the same CSS/JS as page A that it recently requested?

Reply on news.ycombinator.com