3 ms·
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
by 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 agoYeah, 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 agoyou 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 agoeven 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.