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

On 6 August 2014 04:05, Matthew Cox <macox@microsoft.com> wrote:

> Currently I’m able to do all of my stream state management/transitions
> without having to do any interpretation of the payload.


That is a good thing to strive for !  (and it is one of the things I
dislike most about the draft that we have to look at frame type before we
can look for END_STREAM flag).

But, if we are ever to carry non-HTTP protocols over streams (eg
websocket), then I think it is really important to not enforcing HTTP
semantics in the streaming layer. So I don't think the HTTP semantics
described in 8.1 are something that you need to tracked in the framing
layer / stream management.

It should not be the framing layers job to police HTTP semantic
consistency.  For example checking that any content-length sent is the same
as the amount data actually sent is not something that should be done in
the framing layer, nor if the status value is actually an integer nor any
of the many other ways you can create an invalid HTTP message.

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.

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.