Re: Our ALPN protocol IDs

[Martin Thomson <[e-mail]>]

On 5 December 2013 12:26, Willy Tarreau <[e-mail]> wrote:
> so what needs to be documented is more how to pick the best
> version when several ones are compatible between two agents.

That's inherent in ALPN at least: the server picks the option that
suits it best.  The same goes for Upgrade.  Alt-Svc/Alternate-Protocol
let the client pick, unless that means encountering ALPN or Upgrade on
the way there.  The main thing is, all mechanisms will unambiguously
select just one protocol stack.

> I don't see why it would be useful to insist on pretending to be 2.0 when
> connecting to a 2.0 and at the same time expect 2.1 to be transported if
> you can't gain any benefit from this. I even fear that we could reintroduce
> the 1.0/1.1 issues that proxies had to suffer about for decades by doing so.

That's a reasonable point, and I think one that others expressed too.
The amount of flexibility we allow within a single negotiation
protocol version is something we're still discussing.  Some want
basically zero flexibility (I tend to favour this, but not strongly).
Others understandably want to be able to experiment within the
envelope allowed by the protocol.  For HTTP/2.0, that's currently a
very narrow envelope.  That might change if we do something like
http://tools.ietf.org/html/draft-bishop-http2-extension-frames-00
(though I understand that even the author of this draft doesn't really
like this idea any more :)