- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Tue, 9 Jun 2015 11:44:57 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
I find ALPN identifiers highly useful and understand the distinction from URI schemes. My argument is that ALPN identifier use has, because they are so nice, replaced URI scheme use where schemes are needed. ALPN identifiers denote protocols. URI schemes denote protocol stacks. If we want something that denotes a named protocol over another named protocol stack, a simple concatenation. If we take ‚:‘ because it’s not part of a URI scheme (and assume that future ALPN identifier refrain from using it), we get Alt-Svc headers like Alt-Svc: http:h2=„:8000", https:h2=":8001" And if one really wants to keep it short, make "https:" the default if no ':' are present and have Alt-Svc: http:h2=„:8000", h2=":8001" > Am 08.06.2015 um 19:46 schrieb Martin Thomson <martin.thomson@gmail.com>: > > 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 >> >> >> >> <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Received on Tuesday, 9 June 2015 09:45:23 UTC