- From: <K.Morgan@iaea.org>
- Date: Wed, 6 Aug 2014 10:04:52 +0000
- To: <gregw@intalio.com>, <macox@microsoft.com>
- CC: <ietf-http-wg@w3.org>
- Message-ID: <0356EBBE092D394F9291DA01E8D28EC2011E342554@SEM001PD.sg.iaea.org>
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] 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.
Received on Wednesday, 6 August 2014 10:05:30 UTC