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

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".

It's much more consistent if ALPN identifiers are used to identify a
protocol stack, top-to-bottom.  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.

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.

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

Received on Tuesday, 25 February 2014 20:12:33 UTC