Hacker News Reader

Comment by skyde | Hacker News Reader

a push is an HTTP2 stream. the stream header contain everything the client need to know if it already have that file.

If it does already have that file, client simply close the stream it doesn't need to download the file or send request to server to say it doesn't need the file.

View on HN

Even then, the average case would still be worse because the server would be sending all these unnecessary stream headers and forcing the client to send so many unnecessary RST_STREAM frames back. Each PUSH_PROMISE is supposed to contain the full set of headers for each resource.

I guess I hadn’t realized that clients could RST_STREAM on these pushes, but it doesn’t change the outcome here.

What you describe isn’t a win for anyone except a client with a cold cache, and then they start losing immediately after that. That’s why it isn’t done. That’s why HTTP/2 Push is going away.

Even if a client does a RST_STREAM, the origin server might already have done a lot of additional work (e.g. request the pushed file from an upstream if it's a proxy/CDN), and probably stuffed min(TCP_SEND_BUFFER_SIZE, STREAM_FLOW_CONTRO_WINDOW) of data into the stream. Which then also means all of that work might get billed if the server is a managed service. It's really quite some waste of resources compared to the client sending an additional request (which might even be a conditional request).

Yeah, and unless I’m wrong, this also means the TTFB could be significantly higher, since I think the PUSH_PROMISE frames need to come before the main content. Doing that at least requires gathering up the information on those objects, which takes time.

you are 100% right :-(

The spec say

"The server SHOULD send PUSH_PROMISE (Section 6.6) frames prior to sending any frames that reference the promised responses. This avoids a race where clients issue requests prior to receiving any PUSH_PROMISE frames."

even if a server implements that behavior, it could however just send the PUSH_PROMISE frame (containing HTTP headers) but doesn't have to send the associated data frames yet. The frames associated with the original response could follow earlier.

yeah depend if you care more about saving bandwidth or reducing the time it take to display the page.

As noted in other comments on this thread, increasing the TTFB is not a way of displaying the page faster.

HTTP/2 Push is such a cool concept, but the idea of it going away also makes perfect sense to me after years of not seeing anyone find benefit.

The http/2 stream is multiplexed over a regular tcp stream. At least some push HEADERS and data was most likely already send over the tcp stream, and is most likely already a few hops away from the actual server. By the time the server actually gets the first http/2 RST_STREAM(s) a lot of data from multiple useless pushes could be inflight already. At this point you cannot just close the http/2 stream to avoid data being send. You can only either RST the entire tcp stream and kill all multiplexed http/2 flowing over it (avoiding some data transfer), or accept the data that arrives on your closed http/2 streams and send it in the direction of /dev/null.

Server push, as opposed to preload/hints, only makes sense when you know a) a client will absolutely need the data and b) you're reasonably sure the client does not have the data yet (e.g. data that is uncacheable).

Reply on news.ycombinator.com