W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: [#153] PUSH_PROMISE headers

From: James M Snell <jasnell@gmail.com>
Date: Tue, 2 Jul 2013 13:29:55 -0700
Message-ID: <CABP7RbebMCZfiQP6yBct8WD4-Ze6ghdkxyVSaJZXFV2K-3-eqw@mail.gmail.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
I would say, "All request headers the server has assumed for the
implicit request". The difference is subtle but worth it.

On Tue, Jul 2, 2013 at 1:24 PM, Mike Bishop
<Michael.Bishop@microsoft.com> wrote:
> 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:30:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC