RE: HTTP Layer rework and PUSH_PROMISE contents

[Mike Bishop <[e-mail]>]

Isn't that the definition of a SHOULD?  Not necessary for protocol interoperability, but there are strong reasons why it ought to be done that way.  I agree that there are unpleasant results if the sequence isn't there -- I just question whether that makes it a protocol MUST rather than a best practice.

To Mike's point, we're not really middleware, since we're the only protocol implementation in the path.  As such, we're the ones responsible for being compliant with the protocol MUSTs.

Sent from my Windows Phone
________________________________
From: David Morris<mailto:[e-mail]>
Sent: ‎6/‎28/‎2013 6:13 PM
To: HTTP Working Group<mailto:[e-mail]>
Subject: Re: HTTP Layer rework and PUSH_PROMISE contents


I think the SHOULD is pretty strong ... not referencing the outcomes
from the SF Interim, but I think I recall an acknowledgement in the
meetihg that the only way to preclude a race condition with the
client requesting what the server was going to promise was to have the
PUSH_PROMISE sent before any primary response references to the resource.

If this conditions isn't met, I foresee a lot of wasted bandwidth between
client initiated requests and PUSH_PROMISEs for the same resource. Also,
wasted server effort to serve the resource twice.

This issue could be quite important when the last mile to the client is
relatively slow OR the user pays for bandwidth.

I'm not arguing for MUST, but I think a mechanism will be required to
manage the downside if it isn't MUST. A setting or response flag that
gives the client a hint that PUSH_PROMISES are anticipated so the client
should avoid agressive parse/pre-fetch.


On Fri, 28 Jun 2013, James M Snell wrote:

> That's why review is good :) the requirement upgrade was unintentional. If
> possible, can you make a note on the pull request?
> On Jun 28, 2013 5:11 PM, "Mike Bishop" <[e-mail]> wrote:
>
> >  In draft-ietf-httpbis-http2.xml:****
> >
> > >  ****
> >
> > > +        <t>****
> >
> > > +          The server can choose to send one or more push promises****
> >
> > > +          associated with the response. These notify the client that ****
> >
> > > +          the server intends to deliver additional resources to the client****
> >
> > > +          as specified in <xref target="PushResources" />. If the server****
> >
> > > +          sends PUSH_PROMISE frames, those MUST be sent prior to sending ****
> >
> > > +          any header blocks or DATA frames that reference the promised resources.****
> >
> > > +          For instance, if the server receives a request for a document****
> >
> > > +          containing embedded links to multiple image files, and the ****
> >
> > > +          server chooses to push those additional images to the client, ****
> >
> > > +          all of the push promises MUST be sent prior to sending the DATA frames ****
> >
> > > +          that contain the image links. Likewise, if the server pushes ****
> >
> > > +          resources referenced by the header block (i.e. using Link headers), ****
> >
> > > +          the server MUST send the push promises before sending the header****
> >
> > > +          block.****
> >
> > You're upgrading a SHOULD in the current spec to a MUST. Has this been
> > discussed on-list?****
> >
> > Speaking as the http.sys owner for Windows, this concerns me. We don't
> > know the content of the entity body fragments or response headers an
> > application hands us, only the order. The only way we can definitively
> > comply with this MUST is to make all PUSH_PROMISE frames precede all DATA
> > or HEADERS frames. As a SHOULD, we're free to leave proper behavior to the
> > app using our APIs, while maintaining non-optional protocol compliance at
> > our layer. ****
> >
>