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

On 6 August 2014 20:04, <K.Morgan@iaea.org> 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 <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.