Re: h2 frame layout

On 31 August 2014 03:32, Roy T. Fielding <fielding@gbiv.com> wrote:

> I don't see any point in engaging in a self-defeatist argument
>

Sorry for predicting doom if we debate the detail of these proposals.   I
just think that regardless of technical merit, they will meet the same fate
within the WG as other similar proposals - unless we reconsider the charter
or there is some other external influence to stop us iterating on these
points.


>
> BTW, none of those suggestions change semantics.
>

Well maybe not strictly a semantic change, but B is certainly a significant
change that can't be made without forcing further significant change in the
protocol (which is not necessarily a bad thing).   I think the protocol has
a number of highly co-dependent design decision that while they are self
consistent, also make it very fragile to change.

In this case, the current design has tried to enforce HTTP semantics by
making it impossible for the protocol to carry END_STREAM in some locations
that are not legal HTTP frame sequences - eg within a partial
header/trailer or after a push promise.   If the protocol can carry
END_STREAM on any frame, then this is a significant change:

At the very least, implementations that were assuming the illegal HTTP end
streams could not be received would need to explicitly check for them (not
a bad thing).

Then, if a HTTP stream does receive an END_STREAM in an illegal position,
is this a protocol error or just a stream error?  There are valid reasons
for servers/clients to abort partial HTTP messages so it would be good to
make sure the protocol can handle such termination as a stream error and
not discard the entire connection.  However this means we have to define
hpack state handling of partially received headers.

We would also have to define what it means to receive a RST_STREAM frame
that did not have the END_STREAM flag set?   Is this a non-terminal error?
a protocol error?  or do we still need RST_STREAM frame?

Finally, removing END_STREAM from some frame types removes the only
significant difference between HEADER frames and  CONTINUATIONS frames (
other than the optional priority field that can be sent in it's own frame
anyway).    Thus there would be no reason to have the continuations frame
and we should instead just use multiple HEADER frames.

So while I definitely would like to see significant changes/simplification
of the framing layer, I think we have to be very careful to check that we
have not built a house of cards on those particular foundations.  I don't
think there are many easy/simple changes that can be made at this level
with a wide re-evaluation of the entire design.
regards


-- 
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.