Re: HTTP/2, "h2t" and protocol identifiers in general

On 26 Feb 2014, at 7:12 am, Martin Thomson <martin.thomson@gmail.com> wrote:

> One of the proposals in Mark's Alt-Svc draft [1] is the creation of a
> new ALPN token "h2t" that is used to identify a TLS service that is
> willing to accept requests for http: resources.
> 
> This made me think that perhaps we have this all backwards.  I think
> that we instead need an identifier for the cleartext variant of
> HTTP/2, and the identifier that Alt-Svc wants to use in this case
> already exists: "h2”.

My intent was always to use one protocol identifier for TCP+HTTP/2, and another for TCP+TLS+HTTP/2. The idea being that eventually you might have identifiers for QUIC+HTTP/2 or TCP Minion + TLS + HTTP/2 or whatever as well.

So,

HTTPS URI = always h2t
HTTP URI as we know it = h2
HTTP URI w/ TLS = h2t

> It's much more consistent if ALPN identifiers are used to identify a
> protocol stack, top-to-bottom.

Exactly.

>  That means that "h2" identifies HTTP/2
> + TLS + TCP.  If we define "h2t" as Alt-Svc proposes, we change the
> meaning of ALPN identifiers to include the type of thing that the
> protocol carries.

Er? The intent was to identify the stack, and constrain what stacks different URI schemes could run on (especially HTTPS). That may have been lost in rewrites, etc. but it’s always been the intent.

> To make this a clean distinction, we have to stop using "h2" to also
> identify HTTP/2 + TCP (without TLS).  Instead, I propose that we use
> "h2t" for this.

Backwards but yes in spirit.

> 
> It's also the case that I don't want to create a special case for
> http:// URIs here.  We've taken steps toward being able to carry other
> forms of URI in HTTP/2.  Singling http: out for special treatment as
> Alt-Svc proposes seems like a mistake.
> 
> I'll note that this leaves HTTP/1.1 in a little bit of a bind.  ALPN
> defines "http/1.1".  That seems to be what people are using to
> identify HTTP/1.1 + TLS + TCP.  Maybe, just maybe, we can exploit the
> fact that this is lowercase in ALPN and uppercase in RFC 2817 and
> pretend that this isn't an issue.  "http/1.1" is HTTP/1.1 + TLS + TCP;
> "HTTP/1.1" is HTTP/1.1 + TCP.
> 
> [1] http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-03
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 27 February 2014 01:15:27 UTC