W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 27 Feb 2014 10:22:39 -0800
Message-ID: <CABkgnnWEUtb=pFeq-+BkMs1Qy+af0GqvRxDuY+W6B9wyLVeO+g@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 26 February 2014 19:49, William Chan (陈智昌) <willchan@chromium.org> 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

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

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

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

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

Yes.  ^^
Received on Thursday, 27 February 2014 18:23:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC