Re: reserved flags and extensions

Hi Greg,

On Mon, Jul 14, 2014 at 10:51:45AM +1000, Greg Wilkins wrote:
> Willy,
> 
> I think that the only realistic way of expecting h2 extensions to have
> worked through intermediaries was to have a framing layer that was
> independent of HTTP semantics.   Then perhaps we could have had websocket
> and similar type extensions work (although there is still an issue with
> common routing meta data).
> 
> Because we have conflated HTTP semantics with framing, then the only way to
> extend h2 will be to make your extended traffic look exactly like
> non-extended http - regardless of semantics.
> 
> Unfortunately this is exactly the kind of protocol misuse the charter was
> asking us to fix.  But then I think the charter kind of snookered us here
> by asking us to fix the misuse, but then saying that we are only chartered
> to carry HTTP semantics.

Here my comments were not related to HTTP, just encoding. We've been used
to see bad intermediaries only sniff packets, other ones work in tunnel mode
and work as TCP proxies and just slightly mangle what passes through (haproxy
used to do that in its early versions), etc... We know that these ones can
cause trouble because they don't modify Connection or so. Here it will be
the same, with h2 we'll have some intermediaries capable of parsing the
framing to keep in sync and which will not have per-request buffer. They
won't interfer with flow control because they'll pass every frame they
receive. And if/when we later decide to slightly improve the framing as
was already suggested, they'll break, so as a result we'll always refrain
from doing any such change even as an extension by fear that these
undetectable intermediaries will fail and possibly hang. Note that this
is only about the framing and not about the transported protocol. That's
why I think we should take some advance on this and tell them how they
can ensure they'll remain compatible with future versions at a low cost
(eg: trim extensions or just clear one or a few bits).

We have an advantage over h1 : the protocol is so much non-obvious that
it requires implementers to read the spec. 15 years ago, everyone would
proudly implement his own server/client/proxy/gateway without reading
the spec, because he (thought he) knew. Here we're sure that the advices
will be (at least) read.

Willy

Received on Monday, 14 July 2014 06:06:01 UTC