Re: reserved flags and extensions

On Sun, Jul 13, 2014 at 01:21:05PM -0700, Martin Thomson wrote:
> On 13 July 2014 10:37, Willy Tarreau <w@1wt.eu> wrote:
> >> 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.
> >
> > The problem here is that it may quickly require a large number of versions
> > especially if multiple extensions are defined.
> 
> I think that this is the path we walk.  Anything major will need a new
> ALPN tag.  I would certainly advise people that this is better than
> something else.

I know but it's possible that we'll have different compatible extensions,
and that will make it harder to use with ALPN since you'll have to advertise
all combinations.

> That said, I'm not particular sympathetic to the use case of having an
> intermediary that isn't really a participant in the protocol.  I know
> this happens, but I think that the onus is on those entities to deal
> with the consequences of the protocol, in all its aspects.  That means
> not passing on settings (and frames, etc...) they don't understand.

I agree, which is why I'd like to add some wording to their intent. In my
experience, you don't design an intermediary which breaks on purpose, you
just try to implement the minimalist set of features that ensures your code
works well for all your use cases. Haproxy started this way. It used to
only rewrite some cookie headers for a benchmark. Quickly it had to pass
"Connection: close" because it didn't handle keep-alive. And that was enough
for a long time. We all know how a convenient hack quickly becomes a widely
deployed product... If we help implementers avoid the biggest errors, it
may not work optimally for them but it will not break.

I think that requiring that tunnels which have to follow the framing remove
unknown extensions from settings frames (but not the frame since it may
require an ACK) and clear all reserved bits would be a minimum explicit
requirement. In order to make that more likely to be correctly implemented,
I was thinking that we could decide that no extension would modify the
framing without using one of the reserved bits, so if we only require
them to clear reserved bits, it should be enough for recipients to ignore
problematic extensions.

Willy

Received on Monday, 14 July 2014 06:19:10 UTC