Subject: HTTP/2.0 protocol identifier string (#323)

From: Martin Thomson <[email-masked]>
Date: Sat, 16 Nov 2013 21:31:42 -0800

Patrick has generously provided us with a pull request.

https://github.com/http2/http2-spec/pull/323

""
TLS Client Hello's between 256 and 512 bytes need to be rounded up to
512 for compatibility reasons. This incents us to keep Client Hello
parameters as small as possible to avoid the rounding - this change
shortens the ALPN token of HTTP/2.0 to be simply "h2"
""

Those who have been following the ALPN drama might find this
attractive.  Does anyone find this change objectionable?

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 17 Nov 2013 18:47:56 +1300

> attractive.  Does anyone find this change objectionable?

Abbreviating this far and with the ALPN guys not wanting to use binary
token prohibits ALPN being used for sub-versions of HTTP/2.x.
 Do we consider that to be a good or bad thing?

Where can we find the details substantiating those claims of backward
compatibility and that the "HTTP/2.0" string is causing trouble?

What is ALPN requiring of the other protocols to meet this problem?

What is expected to happen with other h* / H* protocols?
 HTCP-over-TLS for example?

Amos

---

From: Martin Thomson <[email-masked]>
Date: Sat, 16 Nov 2013 21:55:53 -0800

>  Do we consider that to be a good or bad thing?

I don't think so.  "h2.1" or "h21" could easily work for HTTP/2.1.

> compatibility and that the "HTTP/2.0" string is causing trouble?

The TLS WG list, or here:
https://www.imperialviolet.org/2013/10/07/f5update.html

> What is ALPN requiring of the other protocols to meet this problem?

I don't understand the question.

>  HTCP-over-TLS for example?

Despite appearances, we aren't defining a prefix.  The use of "h2-09"
would be an unsafe, off-the-books thing that has no guarantees of
uniqueness.  Unless it sees wide deployment, in which case we can
register it to avoid that issue.

Other protocols would be unable to use "h2", since we got there first.
 (They can have "H2" if they are crazy enough.)

---

From: Patrick McManus <[email-masked]>
Date: Sun, 17 Nov 2013 10:09:00 -0500

>  Do we consider that to be a good or bad thing?

the token is only valid as a whole string match.. so h2.1 would be fine.

> compatibility and that the "HTTP/2.0" string is causing trouble?
a decent thread:
http://www.ietf.org/mail-archive/web/tls/current/msg10405.html

also agl's imeperial violet blog is a good source.

we're fortunate that there is a workaround now (round 256-512 up to 512
with padding). I hadn't offered this htp2-draft change before because ALPN
seemed completely unworkable without the workaround - at this point it
seems operationally plausible, but we do want to at least try and avoid the
padding when possible.

There are lot of factors that contribute to going over 256 (resumption,
SNI, ALPN set, etc..) - but keeping this new element as brief as possible
can only help if we're going to put it in every handshake.

>  HTCP-over-TLS for example?
Its handled at token registration time. Implementations would consider the
totallity of the imapct when they choose whether or not to include the alpn
string that the other protocol decides on.

overall not a big deal - just a little tweak.