Re: h2 use of Upgrade

On Wed, Sep 03, 2014 at 03:37:50PM -0700, Roberto Peon wrote:
> Not in the ALPN-based connectivity case, at least, implying different
> codepaths (and a required increase in verbosity near the start of the
> communication) for upgrade vs ALPN-based negotiation.
> 
> Not specifying the ALPN token is also different in the upgrade case as the
> ALPN token might indicate more information in the future about what
> extensions are available, etc. which isn't something conveyed by settings
> alone.
> For anyone wishing to have equivalent functionality/latency for upgrade as
> with ALPN or its future replacements, it would be good to offer the ALPN
> token in there somewhere.

The thing is that ALPN is a lower layer in the TLS stack, I mean it's
meta-data related to a stream connection that is offered by TLS to
transport HTTP/2 (or any other protocol). It could be seen as an
equivalent of the destination TCP port for TCP.

Currently we're using it in TLS to advertise the h2 name to indicate
to the server on the other side what application layer protocol we're
going to speak. In the case of HTTP/1 upgrade we have to advertise an
application layer protocol belonging to a different namespace.

Thus I'm seeing alternative possibilities :
  - either we consider that HTTP/2.0 designates exactly one application
    level protocol and that exactly one name+version must exist for each
    ALPN equivalent. That would more or less imply that the second digit
    continues to designate small protocol variations (eg: HTTP/2.1, etc).

  - or we consider that we're upgrading to an intermediate application
    layer that we could call "ALPN" and that we pass the protocol name
    from the ALPN namespace in a new header (sec-alpn-protocol-list or
    whatever we want to call it).

The second option doesn't seem stupid, as it would provide the closest
equivalent in clear over HTTP/1 to what is offered in secure mode over
TLS+ALPN and would make future upgrades easier. It could even make it
easier for intermediaries to be immediately compatible with future
versions.

Just my two cents,
Willy

Received on Thursday, 4 September 2014 06:20:13 UTC