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

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Feb 2014 12:12:05 -0800

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

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 26 Feb 2014 11:38:30 +0000

> meaning of ALPN identifiers to include the type of thing that the

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.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 26 Feb 2014 08:02:33 -0800

I think you may be conflating scheme and protocol, which are possibly
different?

-=R
On Feb 26, 2014 3:42 AM, "Salvatore Loreto" <[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Feb 2014 08:58:51 -0800

> I think you may be conflating scheme and protocol, which are possibly

I think that Roberto is right here.  And I think that we may have all
been saying the right things, but ignoring the fact that we were doing
the exact wrong thing.

I don't think that this does change the meaning of the ALPN
identifier, so much as the meaning of the ALPN identifier that it
relies on needs changing.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 27 Feb 2014 12:14:59 +1100

On 26 Feb 2014, at 7:12 am, Martin Thomson <[email-masked]> wrote:

> 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

> protocol stack, top-to-bottom.

Exactly.

>  That means that "h2" identifies HTTP/2

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.

> identify HTTP/2 + TCP (without TLS).  Instead, I propose that we use

Backwards but yes in spirit.

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 26 Feb 2014 19:49:48 -0800

I re-read this a few times and still don't grok. I think I'm missing
something. Can someone point out the error in my understanding?

Martin says the ALPN identifier should identify the full protocol stack.
Why is this necessary? When you're doing ALPN, you know you're on TLS
already. AFAICT, it looks like the reason that this is stated here is
because Alt-Svc also uses ALPN tokens, and it wants to identify what
protocol to use for the alternate service. In Alternate-Protocol, we don't
use the same identifier as we did in NPN. We specifically used stuff like
npn-spdy/2 or npn-spdy/3 (npn implies tls).

I'm also confused why "h2t" is used to identify a TLS service that is
willing to accept requests for http:// resources. Is that so we can
discover it during the ALPN negotiation itself? Otherwise, I would think
that discovery of http:// acceptance comes from the advertisement mechanism
in Alt-Svc or DNS or whatever.

Is the proposed redundancy in ALPN tokens there because we want to use the
exact same token in Alt-Svc too?

Just to be clear, my confusion and questioning is not disagreement. I'm
simply trying to grok the discussion here.

On Wed, Feb 26, 2014 at 5:14 PM, Mark Nottingham <[email-masked]> wrote:

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

---

From: Roberto Peon <[email-masked]>
Date: Wed, 26 Feb 2014 20:13:15 -0800

What I'd like to see is the following.
h2 means that we're using the HTTP/2 protocol, and it implies at minimum
that the server supports accepting whatever is the default protocol for the
port, typically HTTPS if using ALPN.
The scheme defines the application-layer semantics of any particular stream.

That h2 implied acceptance of HTTPS on :443 or HTTP on :80 would not
preclude using another scheme.

S
I am really not interested in seeing a combinatorial explosion of ALPN
identifiers-- if I thought we were identifying everything about the
protocol stack, etc. then I'd push for a structured identifier for ALPN
instead of the opaque tokens we currently have.
In fact, we may want to impose a minimal escape-hatch ALPN token
identifiers today to ensure that we can impose such in the future, i.e. if
we fail to anticipate how ALPN will be used in the future.
This could be as simple as saying that everything that doesn't begin with
'_' is unstructured), and thus indicate that tokens must not be registered
with '_'.

-=R

On Wed, Feb 26, 2014 at 7:49 PM, William Chan (陈智昌)
<[email-masked]>wrote:

> that discovery of http:// acceptance comes from the advertisement
> mechanism in Alt-Svc or DNS or whatever.
>
>> lost in rewrites, etc. but it’s always been the intent.
>>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Feb 2014 10:11:11 -0800

> HTTP URI as we know it = h2

That was the point that confused me.  I thought that you were
proposing only the last, without the first change.  Sounds good,
though I would reverse the labels (as originally suggested).

This however, I can't really get behind Roberto's associated implications:

> preclude using another scheme.

This relies heavily on things being implicit, and side effects.

If I want to offer "h2" (or "h2t") on a non-standard port, I would
really like to avoid the implication that I also provide service on
443 or 80 as a result.  Such an implication has consequences that I'd
like to avoid.

I don't really see what this buys.  We've discussed permitting the
service of http: resources that omit the port number over TLS on port
443.  That's already stretching my tolerance for behaviour based on
implicit signals.  But I've been convinced that it's useful.  I'm also
happy that it is sufficient.

(I'm ok with the part about having the scheme defining what semantics
are expected of the protocol.  That's what they already do, basically.
 Contradicting that would be a big mistake.)

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Feb 2014 10:22:39 -0800

On 26 February 2014 19:49, William Chan (陈智昌) <[email-masked]> wrote:
> Martin says the ALPN identifier should identify the full protocol stack. Why
> is this necessary? When you're doing ALPN, you know you're on TLS already.
> AFAICT, it looks like the reason that this is stated here is because Alt-Svc
> also uses ALPN tokens, and it wants to identify what protocol to use for the
> alternate service.

The important point here is that ALPN identifiers are not restricted
to use in ALPN only.  That generality allows us to use the identifier
in the Upgrade header field, as well as Alt-Svc.  But in order for
them to be generally applicable,

Maybe we should just call them protocol identifiers.

I understand how Alternate-Protocol scoped identifiers, which is
appropriate for a narrowly focused solution.  The virtue of a more
general solution is that it can be used elsewhere, as has already
started with

> willing to accept requests for http:// resources. Is that so we can discover
> it during the ALPN negotiation itself? Otherwise, I would think that
> discovery of http:// acceptance comes from the advertisement mechanism in
> Alt-Svc or DNS or whatever.

The idea is that "h2t" is used to label a protocol endpoint.  As
described in Alt-Svc, that label states that the endpoint supports
HTTP/2 over TLS over TCP (etc...).  If you support "h2t", then you can
negotiate the use of that stack.

What is most important here is that you don't learn from this exchange
that the server will accept requests for http:// URIs.  You will have
gotten that signal elsewhere, in this case from an Alt-Svc header
field on a response from (probably) port 80.

If we define a DNS record, the DNS will provide a function in the
form:  var (protocol, ip, port) = resolveProtocolEndpoint(scheme,
authority, [supportedProtocols...]).  That would provide the same
signal.

(As proposed by Mark, "h2" would be exclusively for HTTP/2 over
cleartext TCP; I'd prefer to swap the labels, but we know what we call
that sort of argument.)

> exact same token in Alt-Svc too?

Yes.  ^^

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 28 Feb 2014 16:09:03 +0000

> cleartext TCP; I'd prefer to swap the labels, but we know what we call

I’d be OK with “h2” for TLS and something like “h2p” (for “plaintext”).

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 01 Mar 2014 14:57:35 +1300

> I’d be OK with “h2” for TLS and something like “h2p” (for “plaintext”).

FWIW: I prefer the orginal proposal where the 't' signified the
injection of TLS layer between HTTP/2 and TCP.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 01 Mar 2014 18:19:38 +1300

On 1/03/2014 3:25 p.m., Matthew Kerwin wrote:
> On 1 March 2014 11:57, Amos Jeffries wrote:
> 
>>> On 27 Feb 2014, at 6:22 pm, Martin Thomson wrote:
>>>
>>> I'd be OK with "h2" for TLS and something like "h2p" (for "plaintext").
>>
>>
> And my two cents, because I love painting sheds: I prefer 'h2s' for HTTP/2
> over TLS, for its symmetry with http/https.
> 

I thought about suggesting that, but we are actually wanting to *detach*
the symmetry.

 => h2t in the proxy cases TLS without meaning HTTPS specifically.

Amos