- From: Roberto Peon <grmocg@gmail.com>
- Date: Fri, 28 Jun 2013 22:34:39 -0700
- To: James M Snell <jasnell@gmail.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNd9BDHBO2YXEfHwvRuiJDDpbAEvCMR2BKLzcoaARxjDJA@mail.gmail.com>
Any content negotiation would be an appropriate example. :) You don't want to have to wait for the HEADERS frame to indicate to the client which resource it might already have (it should have the opportunity to RST_STREAM if it has it in cache, for instance). -=R On Fri, Jun 28, 2013 at 10:25 PM, James M Snell <jasnell@gmail.com> wrote: > Have an example handy? > > Here's an example that shows that response headers in the PUSH_PROMISE > would not be necessary... Let's say I send a PUSH_PROMISE with the > following bits of info... > > PUSH_PROMISE > :path = /images/f.jpg > :method = GET > :host = example.org > :scheme = http > accept = image/jpeg > if-match: "my-etag1" > cache-control: max-age=1000 > > These headers are giving me everything I would need to determine if > there is a matching resource in my local cache. I have the method, I > have the etag, I have the cache-control parameters, accept... There's > no need for response headers at this point. > > Later, once I start accepting the frames for the pushed content, I > would get something like... > > HEADERS > :status = 200 > content-type: image/jpeg > content-length: 123 > etag: "my-etag1" > vary: accept > cache-control: public > > On the off chance that the PUSH_PROMISE doesn't give me what I need, > the follow on HEADERS frame will give me the rest. > > > > On Fri, Jun 28, 2013 at 9:55 PM, Roberto Peon <grmocg@gmail.com> 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 05:35:07 UTC