Re: [#153] PUSH_PROMISE headers

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

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