Ilari, 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