- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Mon, 8 Jun 2015 10:46:02 -0700
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
ALPN was invented to deal with a shortcoming of the URI scheme. Specifically, because we needed to use either HTTP/1.1 or (originally) SPDY to interact with https:// resources. I see no problem with defining h2q, if that is the way we go. And h2 isn't in the upgrade registry because we explicitly decided not to support that option. On 8 June 2015 at 06:01, Stefan Eissing <stefan.eissing@greenbytes.de> wrote: > 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 17:46:30 UTC