Hi Greg-
On Wednesday,06 August 2014 00:38, gregw@intalio.com<mailto:gregw@intalio.com> 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] Received on Wednesday, 6 August 2014 10:05:30 UTC