alpn identifiers (not again!)

Probably everyone is tired of this already, and yes, there are tons of mails out there and several issues on github.

However. HTTP/2 is young, there are several draft specs building on top of it. The Alt-Svc spec is the prominent one stumbling over ALPN identifier use. Then there is tunnel-protocol. And more will come (QUIC anyone?). So I add my €0.02 in the hope of moving the mountain…



To have „h2c“ as an ALPN identifier that can never be used in ALPN and missing „h2“ in the Upgrade: header registry (why? enable http/2 on a https connection without ALPN?) shows that there are big holes here. It is unreasonable that any new transport layer protocol would need to write new alt-svc or tunnel-protocol specs or add names into the ALPN registry that will never be usable in TLS.

Will we have „h2q“ as Alt-Svc name for a DTLS secured QUIC transport of HTTP/2? Does not seem attractive to me.

And we *do* already have names and registry for names that define transport protocol stacks, the URL scheme. We have
- „http:“ as cleartext TCP HTTP/1 connection, with protocol negotiation over HTTP Upgrade
- „https:“ as TLS secured TCP HTTP/1 connection, with protocol negotiation over ALPN

With this in mind, a propsoed header like:
   Alt-Svc: h2c=":8000", h2=":443“
could be written as:
   Alt-Svc: h2=„http::8000", h2=„https:“
and in the future maybe:
   Alt-Svc: h2=„quics::1234“
without any confusion of ALPN identifiers and protocol stacks.


tl:dr

I think the distinction between „h2c“ and „h2" is wrong, confusing and limiting future development.

//Stefan

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Received on Monday, 8 June 2015 13:02:21 UTC