Re: [#153] PUSH_PROMISE headers

[James M Snell <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
>> <[e-mail]> 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).
>> >
>>
>