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

On Feb 25, 2014, at 9:12 PM, 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".
> 
> 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.


I don't see why you think the meaning of ALPN identifier is changing with this proposal.

ALPN is a mechanism to negotiate between client and server
when multiple application protocols are supported over a single server-side port number (i.e. 443 port).

Nowadays (i.e. in HTTP/1.1) http:// is over port 80, while https:// is over port 443
therefore are then "two" application protocols transported over two different ports,
and so we need to have two different ALPN tokens.



> 
> 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 Wednesday, 26 February 2014 11:38:55 UTC