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

Re: [#153] PUSH_PROMISE headers

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 2 Jul 2013 13:50:02 -0700
Message-ID: <CAP+FsNfDPPtuCmkZtDc17zd2q1xdEgu+1Vaef3bSiaAvo2K9nQ@mail.gmail.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: James M Snell <jasnell@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
We haven't even had substantive discussions about it yet.

My preference is that we stick everything in there, since otherwise you are
forced to keep the state from the original request around indefinitely, and
that contradicts the intent of PUSH_PROMISE.
The intent of PUSH_PROMISE is that any state allocation done because of
PUSH_PROMISE is minimal and can be dropped safely without causing
correctness issues (you may be getting the resource twice at worst).

-=R


On Tue, Jul 2, 2013 at 1:44 PM, Mike Bishop <Michael.Bishop@microsoft.com>wrote:

> Perhaps too subtle for me.  :-)  Sorry to be pedantic, but that means that
> the only headers on the synthetic request are those which are contained in
> the PUSH_PROMISE?
>
> If so, doesn't that simplify away the text about "required" headers in
> PUSH_PROMISE, since they're the same required headers in any HTTP Request?
>
> -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: Tuesday, July 2, 2013 1:30 PM
> To: Mike Bishop
> Cc: Martin Thomson; Roberto Peon; HTTP Working Group
> Subject: Re: [#153] PUSH_PROMISE headers
>
> 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:50:30 UTC

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