Re: Permissible states for extension frames #591

On 12 August 2014 19:49, Amos Jeffries <squid3@treenet.co.nz> wrote:

> I dont see why we need to do that at all.


The problem is that we have a very strict definition of no interleaving of
frames between continuations.  Not even control frames can be
interleaved.   This allows implementations to treat continuations as simply
an atomically arriving jumbo.

In fact when we discussed the more complete version of the state machine
https://github.com/http2/http2-spec/issues/484 that could handle non atomic
arrival of end_stream and  end_headers, the argument was made that the
state machine should not be complicated in that way.  It was said that
nobody would implement the proposed 1/4 closed and 3/4
<http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/att-0720/http2state.txt>
closed states because you can effectively treat the arrival of an
end_stream and the following end_headers as atomic.

If we allow arbitrary interleaving of extension frames, then we will have
extension frames arriving in the middle of these supposed atomic stream
state transitions that every implementation is going to have elided in some
not specified private way.    Thus it is highly unlikely that portable
extensions that interact with stream state will be able to be developed as
there is not a common definition for non-atomic leap between two defined
stream states.

Also any implementation that wishes to some day support the any extension
frames, cannot be written with the simplified state machine and must treat
headers and continuations as non atomic events.  This is not an impossible
task and if we supported interleaving of continuations frames by other
protocol frames, then it would have to be done anyway.  But unfortunately
because we don't support any interleaving in the default protocol, that
means that any impl that does support the full state machine cannot
actually be tested with the un extended protocol. So there are going to be
a lot of undiscovered bugs that might be exploitable once a few extensions
are implemented long after the more rigorous testing of the stream states
has been done.

The best solution would of been to have a framing layer that was entirely
independent of frame types, so it could have handles stream control without
even needing to know what an extension was.   But that horse bolted long
ago.

We could have taken a step towards that optimum solution by removing
continuations and supporting fragmentable interleavable headers with a
simple stream state machine where end_stream is on the last frame. Sure it
is more complex, but at least it can be tested in a normal use case.  But
we didn't get consensus for that.

So next best would be to allow interleaving of at least control frames
between continuation frames.  This would at least allow  testing the
complexities of 1/4 and 3/4 closed streams but without having many benefits
for this complexity.  Kind of the worst of all worlds, but probably
necessary if we want extensions able to be arbitrarily interleaved.

Failing that, all we can continue to treat continuations as a very special
case and that nothing can interleave, not even extension frames.   Only
then can implementations implement the simplified state machine that was
explicitly used to justify many design decisions.  Unfortunately this means
that all extensions, even ones that don't care about stream state, have to
known about this special case so they don't interleave at the wrong time.

Sorry for the essay, but it is really important to not allow WG fatigue to
let some less-precise wording through.  We've been told that "ugliness" is
not a technical reason for rejecting a design, so we have some ugly parts
in the specification.  The cost of ugliness comes now as every single thing
you add/extend to the specification has to be run past all the ugliness and
we have to make sure that we don't break any of the fragile reasoning or
fictional state machine used to support it.   Non-ugly design is more
robust in the face of change/extension.

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.