- From: <bizzbyster@gmail.com>
- Date: Sun, 3 Nov 2013 07:58:09 -0800
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Message-Id: <6D993832-8638-4FFE-832B-B760566B8F4B@gmail.com>
From section 8.2.1... The server SHOULD send PUSH_PROMISE (Section 6.6) frames prior to sending any frames that reference the promised resources. This avoids a race where clients issue requests for resources prior to receiving any PUSH_PROMISE frames. For example, if the server receives a request for a document containing embedded links to multiple image files, and the server chooses to push those additional images to the client, sending push promises before the DATA frames that contain the image links ensure that the client is able to see the promises before discovering the resources. Similarly, if the server pushes resources referenced by the header block (for instance, in Link header fields), sending the push promises before sending the header block ensures that clients do not request those resources. I know from experience implementing a prefetching proxy, requiring push_promise frames prior to sending frames that reference the promised resources is simpler (you don't have to deal with the race) but it introduces delays. The ideal prefetching proxy does whatever work it needs to identify resources to promise asynchronously so that browser requested data never waits but this means that push_promise frames will often be sent AFTER the frames that reference the promised resources. It's a performance versus simplicity tradeoff that this list may have discussed in the past but I can't find the thread if so. Thanks, Peter
Received on Sunday, 3 November 2013 15:58:36 UTC