Re: [#153] PUSH_PROMISE headers

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

Let's please not conflate compression and push.. they really are
unrelated to one another.

There is really only two reasons for including header fields in a push promise:

1. Identifying the resource being pushed
2. Allowing the recipient to determine if it needs the pushed resource

In HTTP, we already have a client-side caching mechanism that is based
entirely on comparison of a relevant set of request headers against
what is currently stored in the cache. If a new items it added to the
cache, the response headers are used to populate, but it's the set of
request headers that are used to determine cache hits or misses. This
is a pre-existing mechanism that is already very well established.

For the push promise, the request headers give us everything we need
to address #1 and #2 above. Sending the request headers in the
push_promise gives the client side the context it needs to understand
the pushed set of response frames.

Yes, it's understood that the request headers generated by the server
might not match exactly what the client may have sent for the same
resource but that's perfectly ok... This *is* server push after all...
the request headers sent in the push promise would be the request
headers the server has implied for the pushed streams *implied* GET.

The idea of the push promise sending a "preview" of the response
headers is rather nonsensical because (a) the response headers do not
help me address the two goals above (unless they are required to
contain a content-location header) and (b) why send a preview of the
response headers moments before sending the actual response headers?

The idea then, is this: Sending a push promise is the servers way of
saying, "Based on the initial request, I expect that you're going to
send another request that looks like this..." [where "this" is the
assumed set of request headers ] "... therefore I'm going to go ahead
and send the appropriate response without waiting for you to send it."

Compression of the headers does not enter into the discussion in any
way. Compression only deals with how the bits are serialized on the
wire in each direction, not the actual content or use of the headers.

As a future potential optimization, as part of the originating request
sent by the client, I can imagine someone eventually defining a set of
"push negotiation" request headers... something like...

  Push-Accept: image/jpeg, image/png
  Push-If-Match: "resource-1-etag", "resource-2-etag"
  Push-If-Modified-Since: 2013-12-12T12:12:12Z

Which would be interpreted as:

  1. I'll except pushes for JPEG and PNG resources
  2. So long as their entity tags match "resource-1-etag" or "resource-2-etag"
  3. And have been modified after 2013-12-12T12:12:12Z

These kinds of optimizations would make sense *after* we get a lot
more experience with push. Until then, however, having the simple rule
that for pushed streams "PUSH_PROMISE contains Request Headers and
HEADERS contains Response Headers" is simple enough for us to get
started. We can tweak it further later once we get more experience.


On Mon, Jul 1, 2013 at 1:01 PM, Martin Thomson <[e-mail]> wrote:
[snip]
>
> That leads to some interesting questions with respect to compression.
> Maybe the right way to do this is to have PUSH_PROMISE include ALL
> headers from the associated request, and then use that associated
> request as the reference from which compression builds.
>
> Of course, that would be grossly premature, given how little we know
> of usage patterns for push.