4 ms·

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

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.

Matthias247 4y ago
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).
- coder543 4y ago
  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.
  - skyde 4y ago
    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."
    - Matthias247 4y ago
      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.
skyde 4y ago
yeah depend if you care more about saving bandwidth or reducing the time it take to display the page.
- coder543 4y ago
  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.

Matthias247 4y ago

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

coder543 4y ago
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.
- skyde 4y ago
  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."
  - Matthias247 4y ago
    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.

skyde 4y ago

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

coder543 4y ago
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.