Re: [#153] PUSH_PROMISE headers

[Roberto Peon <[e-mail]>]

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).
> >
>
>