Re: reserved flags and extensions

I think regardless of what we do, changing the framing of HTTP/2 will cause breakage by at least a subset of “frame sniffers”, and therefore that is something we shouldn’t do.

If we want a different framing, we should neg^H^H^H advertise it not in HTTP/2’s SETTINGS frame, but in ALPN/Upgrade and call it HTTP/3 or HTTP/2.1. 

Yoav

On Jul 13, 2014, at 9:06 AM, 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
> 
>

Received on Sunday, 13 July 2014 12:57:37 UTC