RE: [#153] PUSH_PROMISE headers

Did we have consensus here on whether PUSH_PROMISE in the Implementation Draft contains *all* request headers or simply the ones that have changed from the original request?

The more I think about it, I'm inclined to say "all" since the server can drop any headers it knows it won't be looking at if it wants, and headers that are the same will just get compressed out after they've been pushed back once.

That seems simpler than trying to contort header compression to change what the initial context is.

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Monday, July 1, 2013 1:02 PM
To: Mike Bishop
Cc: Roberto Peon; James M Snell; HTTP Working Group
Subject: Re: [#153] PUSH_PROMISE headers

On 1 July 2013 11:44, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> There are some wasted bytes if the server sends back the entire 
> request headers, since the headers are supposed to be copied from the 
> initial request and the client already knows what it sent.  Are we 
> presuming that the server is sending back only the headers whose 
> values it wants to override?  (If so, how does the server express that 
> it wants to drop a header, override it to empty?)

I think that this is the bit that will need additional refinement.  As this describes, the headers that are included in PUSH_PROMISE replace headers (or add new ones) that are in the associated request.

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 Tuesday, 2 July 2013 20:26:03 UTC