Re: [#153] PUSH_PROMISE headers

I would avoid conflating the client caching semantics with the request identifying push headers. In fact, I would err on the side simplicity for this mechanism. For example, since these subsequent requests are based on the initial page you can likely use only the URL to identify the pushed resource. Both a browser and an API client should have a well defined way of tracking subsequent requests back to this parent request. Varying the pushed resources based on different request headers rather than just the URL and parent request seems fraught with edge cases.

A real question I have is whether it even makes sense to push the content right away when you could just send down the list of resources? You'd only lose one RTT and depending on network speed and size of the initial request that could end up being net zero additional latency.

Sam

On Jul 1, 2013, at 1:20 PM, James M Snell <jasnell@gmail.com> wrote:

> 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 <martin.thomson@gmail.com> 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.
>

Received on Monday, 1 July 2013 21:04:48 UTC