- From: James M Snell <jasnell@gmail.com>
- Date: Fri, 28 Jun 2013 17:28:41 -0700
- To: Mike Bishop <Michael.Bishop@microsoft.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CABP7RbceLmh4dawBQjqVyF4BeF92sfSSVMXJMjYY+txPh0zGTg@mail.gmail.com>
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" <Michael.Bishop@microsoft.com> 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. **** >
Received on Saturday, 29 June 2013 00:29:08 UTC