Re: can h2 extension frames carry data?

On Tue, Nov 03, 2015 at 08:11:21AM +0000, Cory Benfield wrote:
> 
> > On 3 Nov 2015, at 06:36, Willy Tarreau <w@1wt.eu> wrote:
> > Maybe it's not too late to define this classification, implementations
> > will evolve, you just need to be careful to ensure the fallback for those
> > not aware of it is nice enough. Typically if we define such classification
> > and some intermediaries want to inspect contents and are not aware of it,
> > well... they won't find the data they want in gzipped contents and that's
> > all. That will give them incentive to implement the classification and/or
> > support for gzip.
> > 
> 
> How would such a classification work? Add a new registry of frame types that
> must not be ignored, and then have H2 extensions specify whether their new
> frames fall into that category? That works, but only if implementations stay
> up-to-date with it. Any model I can think of where implementations will just
> naively DTRT requires changing the frame header, and that horse has bolted.

The only way I'm seeing this work is by reserving numeric ranges (for
frame types for example). This means that types within a range or above
or below a certain value are marked as "affects the framing or semantics".
These ones will need to be removed by those who don't support them, and
ACKed by those who accept them. That's more or less what is done with TCP
extensions by the way. Firewalls which didn't support window scaling used
to strip the option from the packets so that it was not negociated ; servers
are asked to respond with it to confirm support. And some options used to
cause some breakage because they were defined long after the initial specs.
Here it's the same but we want to let proxies know that something might
break before it's spec'd to avoid the general breakage.

Willy

Received on Tuesday, 3 November 2015 08:59:44 UTC