Subject: stream state management was: 1xx (informational) responses affect on stream management

From: <[email-masked]>
Date: Wed, 6 Aug 2014 10:04:52 +0000

Hi Greg-

On Wednesday,06 August 2014 00:38, [email-masked]<mailto:[email-masked]> wrote:

> [SNIP]

> So I think your streaming layer should pretty much allow any frame type

> sequence through, and only look at frame type just enough to look for

> END_STREAM.....   maybe it must also handle CONTINUATIONs and

> END_HEADERS because of their particular requirements  (more conflation of

> HTTP semantics to the framing layer).    But let it be relaxed about non-http

> frame sequences in a stream, as hopefully we eventually will see non-http

> travelling over streams.

AFAICT, the state machine [1] transitions *are tied to frame type*.  e.g. the transition from IDLE to OPEN occurs on a HEADERS frame, the transition from IDLE to RESERVED happens on a PUSH_PROMISE frame, and the transition to CLOSED can happen on a RST_STREAM frame.

Are you saying that one’s streaming layer could simply transition to OPEN on the first frame received for a particular stream ID?  And one could transition to closed the first time the END_STREAM flag is set (with the obvious caveat that the generic closed state has to allow additional frames for some time e.g. for CONTINUATION and/or other frames that may have already been queued or in-flight).  And then the next layer, the protocol-specific framing layer, worries about whether the frame sequence is valid???

If that’s what you are suggesting, I like it :)  I just wish it was cleanly called out in the spec so all could easily see this non-obvious* option.  In fact it would have been better to have an agnostic streaming layer upon which HTTP/2 is built.

-keith

*non-obvious IMO

[1] http://http2.github.io/http2-spec/#StreamStates

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 6 Aug 2014 20:49:22 +1000

On 6 August 2014 20:04, <[email-masked]> wrote:

> AFAICT, the state machine [1] transitions **are tied to frame type**.
>
agreed.

> Are you saying that one’s streaming layer could simply transition to OPEN
> on the first frame received for a particular stream ID?  And one could
> transition to closed the first time the END_STREAM flag is set (with the
> obvious caveat that the generic closed state has to allow additional frames
> for some time e.g. for CONTINUATION and/or other frames that may have
> already been queued or in-flight).  And then the next layer, the
> protocol-specific framing layer, worries about whether the frame sequence
> is valid???
>
That is indeed what I have previously advocated for..... but at this stage
I'm not suggesting we revisit that.

All I'm currently saying is that framing implementations need not look at
frames in any more detail than necessary to identify key flags.
Specifically they should not look inside the frame payloads for such things
as valid status codes or correct content-lengths in order to try to enforce
HTTP semantics.

> If that’s what you are suggesting, I like it :)  I just wish it was
> cleanly called out in the spec so all could easily see this non-obvious*
> option.  In fact it would have been better to have an agnostic streaming
> layer upon which HTTP/2 is built.
>
Note that SPDY has a clear separation of framing layer and HTTP semantics
carried by that framing.   But unfortunately that horse bolted for http2
some time ago.

cheers

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.