Re: HTTP Layer rework and PUSH_PROMISE contents

[Mike Belshe <[e-mail]>]

On Fri, Jun 28, 2013 at 5:07 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?****
>
> This is part of minimizing races where the client makes the request for a
pushed resource before the server gets around to pushing it.

If the server has the intent to push, it really needs to do so as early as
possible.

I prefer the MUST.  From the client point of view, this means that once
you've received a reference to a resource, you know definitively whether or
not a server will push that resource.


> 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.
>
The reality is that you have no way to check whether a resource is
referenced or not...  unless you build a fully compliant javascript engine,
simulate all possible paths, etc...  :-)

So from this perspective, I agree with you - there is no way for middleware
to enforce correctness.  On the good news side, the spec does not specify
any retaliatory behavior upon receipt of resources which arrive after they
are referenced....

Mike