- From: David Morris <dwm@xpasc.com>
- Date: Fri, 28 Jun 2013 23:04:39 -0700 (PDT)
- To: HTTP Working Group <ietf-http-wg@w3.org>
Without PUSH_PROMISE in the picture, the client would only have the request headers to decide if something in the cache applies to a request. If we expect the PP response header set to be meaningful, then the server needs to do much of the processing before generating the PP headers. With the ordering requirement, this gets really difficult and possibly introduces a new form of head of line blocking. The fly in the ointment that I see is that the client may not actually create the request header set the way the server guessed it would. For example, the client would likely include an eTag if available and the server has no knowledge of what eTag should be in the PP headers. I continue to suspect that PUSH_PROMISE is either not going to be heavily used on the general web or it is going to waste significant bandwidth and server capacity. A PUSH_OFFER approach might be slightly slower (1/2 RTT for the whole set?) but the resource consumption could be similar to the case without either form of pre-fetch. But I'm not advocating a change at this time. Once there are implementations we need to evaluate alternatives carefully. Dave Morris On Fri, 28 Jun 2013, Roberto Peon wrote: > Depending on how the request might have been been constructed, response > headers may be necessary to identify the resource in the cache, as compared > to the resource specified in the HTML (I'm thinking about vary: stuff). > > -=R > > > On Fri, Jun 28, 2013 at 9:44 PM, James M Snell <jasnell@gmail.com> wrote: > > > Let's take a step back and consider what a pushed stream is... > > > > A pushed stream is essentially an "Implied GET". This means that a > > server is going to assume that the client was going to send a GET for > > the pushed resource. This also means that the server has to make some > > assumptions about the make up of that implied GET. > > > > Now, consider how HTTP caching works. When a cache receives a request > > for a resource, how does it determine whether or not it has a > > representation of the resource already available? Does it look at the > > request headers or the response headers? Obviously, it looks at the > > request headers. It uses the response headers when populating the > > cache. > > > > So, if we look at the pushed resource sent by the server, what we need > > is for A) the server to first let us know about the implied GET > > request.. which means pushing down a set of request headers then B) > > the server to send the actual resource, which means pushing down the > > response headers. > > > > Already in our design for pushed resources, we have the server sending > > a PUSH_PROMISE frame that contains a header block, followed by a > > HEADERS frame that also contains a headers block. It stands to reason > > that the PUSH_PROMISE frame would contain the set of request headers > > that the server is assuming for the implied GET. These are delivered > > to the client, which uses those to determine whether or not a cached > > representation of the resource is already available (just as any cache > > would do using the request headers). The server would then send it's > > response headers in a HEADERS frame, just as it would any response to > > any other kind of GET. > > > > Two examples to show how this naturally fits... First, let's look at a > > normal GET request sent by the client to the server... > > > > Client Server > > ------ ------ > > | | > > | ---------------------> | > > | HEADERS | > > | GET | > > | /images/f.jpg | > > | If-Match: etag1 | > > | Accept: image/jpeg | > > | | > > | <--------------------- | > > | HEADERS | > > | 200 | > > | Content-Type: | > > | image/jpeg | > > | Content-Length: | > > | 123 | > > | | > > | <--------------------- | > > | DATA....DATA.... | > > | | > > > > Now consider the same resource being pushed by the server using > > PUSH_PROMISE... > > > > Client Server > > ------ ------ > > | | > > | <--------------------- | > > | PUSH_PROMISE | > > | GET | > > | /images/f.jpg | > > | If-Match: etag1 | > > | Accept: image/jpeg | > > | | > > | <--------------------- | > > | HEADERS | > > | 200 | > > | Content-Type: | > > | image/jpeg | > > | Content-Length: | > > | 123 | > > | | > > | <--------------------- | > > | DATA....DATA.... | > > | | > > > > > > Note that the only difference here is the direction and type of the > > first frame. Everything else is identical. The PUSH_PROMISE contains > > everything the client needs to determine whether or not it already has > > the resource in it's local cache (request URI, etag, content-type...). > > > > There's no need to get any more complicated than this. We already > > require two distinct header blocks for every request. We already send > > two distinct header blocks for each pushed stream. We already indicate > > that a pushed stream is an implied GET. To make it work, we simply > > state that the PUSH_PROMISE contains the Request headers that the > > server has assumed for the implied GET request, while the HEADERS > > frame sent later contains the Response headers. If the request headers > > in the PUSH_PROMISE end up not being adequate enough to properly > > determine if the resource is already cached, then we treat it as just > > another cache miss. > > > > On Fri, Jun 28, 2013 at 5:21 PM, Martin Thomson > > <martin.thomson@gmail.com> wrote: > > > https://github.com/http2/http2-spec/issues/153 > > > > > > The current text describes PUSH_PROMISE as having a few request > > > headers, plus some response headers, but it's quite vague. > > > > > > I think that if this is going to be properly workable across a wide > > > range of uses with lots of different headers, PUSH_PROMISE needs to > > > include two sets of headers: the ones that it overrides from the > > > associated request (:path being foremost of those) and the ones that > > > it provides as a "preview" of the response (e.g., ETag might allow > > > caches to determine if they were interested in the rest of the > > > response). > > > > > > > >
Received on Saturday, 29 June 2013 06:05:08 UTC