Subject: HTTP Layer rework and PUSH_PROMISE contents

From: Mike Bishop <[email-masked]>
Date: Sat, 29 Jun 2013 00:07:17 +0000

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.

---

From: James M Snell <[email-masked]>
Date: Fri, 28 Jun 2013 17:28:41 -0700

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" <[email-masked]> 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. ****
>

---

From: Mike Belshe <[email-masked]>
Date: Fri, 28 Jun 2013 17:55:05 -0700

On Fri, Jun 28, 2013 at 5:07 PM, Mike Bishop
<[email-masked]>wrote:

> 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.

> 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

---

From: David Morris <[email-masked]>
Date: Fri, 28 Jun 2013 18:09:59 -0700 (PDT)

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.

---

From: Mike Bishop <[email-masked]>
Date: Sat, 29 Jun 2013 04:04:00 +0000

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:[email-masked]>
Sent: ‎6/‎28/‎2013 6:13 PM
To: HTTP Working Group<mailto:[email-masked]>
Subject: Re: HTTP Layer rework and PUSH_PROMISE contents

---

From: Martin Thomson <[email-masked]>
Date: Sat, 29 Jun 2013 13:19:43 -0700

On 28 June 2013 21:04, Mike Bishop <[email-masked]> wrote:
> 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.

I agree with this.  I also don't think that it will be possible in
some cases to provide this guarantee.  In many cases it will be
certainly be infeasible.