W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: HEADERS and flow control

From: Michael Sweet <msweet@apple.com>
Date: Wed, 21 May 2014 13:21:19 -0400
Cc: Greg Wilkins <gregw@intalio.com>, David Krauss <potswa@gmail.com>, Mark Nottingham <mnot@mnot.net>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <B8544E2F-E86F-4F15-B1C1-A9EDC53C293D@apple.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>

On May 21, 2014, at 11:53 AM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> On Wed, May 21, 2014 at 10:32:25AM -0400, Michael Sweet wrote:
>> +1
>> Even with the current header compression, there is no reason to prevent
>> intervening DATA frames, or to omit HEADER frames from the
>> scheduling/queuing algorithms that clients and servers must implement
>> for HTTP/2.  The only requirement based on the header compression
>> algorithm that has been adopted is that there can only be a single set
>> of HEADER frames in flight in either direction, and I don't think that
>> is a big step beyond what is already required.
> Well, this is probably fundamentially ill-defined question, but:
> What are the semantics of DATA frames transmitted on stream with HEADER
> block still active? If the HEADER is the first header block? If the HEADER
> is subsequent HEADER block?

On a given stream you won't see DATA frames until all of the HEADER frames have been sent (or received).

But if you are in the middle of sending HEADER frames to create a new stream (or for response headers), DATA frames for existing streams can continue to flow - semantically they are separate streams with separate state.

Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Wednesday, 21 May 2014 17:21:50 UTC

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