Re: reserved flags and extensions

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.

cheers



On 13 July 2014 16:06, Willy Tarreau <w@1wt.eu> wrote:

> Hi,
>
> it has been suggested several times that future extensions could change
> the framing. Reserved flags are marked as "must be sent as zero" and "must
> be ignored on receipt". However, if some intermediary is designed to only
> inspect contents and relay frames as-is (think an anti-virus or so which
> only cares about data and ignores everything else), it might very well
> end up desynchronized when future extensions affecting the framing are
> negociated between the client and the server and it ignores them. This
> is exactly the issue TCP has long been facing with window scaling and
> middle firewalls which did not support it and would block supposedly
> out-of-window packets.
>
> It would be sad to discover 1 year after the protocol is released that
> we cannot update the framing to benefit from the wider experience in
> field, just because of some dumb components breaking the net again.
>
> And the problem of extensions is that nobody is required to know them in
> advance, so nobody knows in advance if leaving them enabled can cause some
> breakage or is desirable.
>
> One radical solution to this I'm seeing is to explicitly require that
> any unknown extension must be removed from the settings frames by these
> "dumb" intermediaries designed to forward everything. This might not be
> the easiest thing for them, and would lead to other useful extensions to
> be removed.
>
> Another solution would help dumber intermediaries and would avoid getting
> rid of all extensions : we can define *right now* that one of the reserved
> bits will indicate "alternate framing settings present" and that all
> extensions which affect the framing rely on this bit to be set. That way,
> the dumber intermediaries which are not capable of updating the settings
> could simply clear this bit and force the communication to fall back to
> the legacy specification, and the recipient will simply ignore these
> extensions.
>
> The last option I'm seeing is to leave things as they are right now and
> to add a specific paragraph in the spec for those dumb intermediaries
> which we could call "frame sniffers" or so, and indicate what the absolute
> minimal amount of processing can be : you can forward everything as-is
> but you MUST at least clear all reserved bits [list here].
>
> What do you think ?
> Willy
>
>
>


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