- From: Mike Bishop <Michael.Bishop@microsoft.com>
- Date: Wed, 20 Apr 2016 17:01:08 +0000
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- CC: Michael Kaufmann <mail@michael-kaufmann.ch>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
I agree with you that using different tokens for the same protocol is a bit silly -- when are we discussing a protocol at one layer versus when are we discussing a stack of protocols? But that's the way the RFC fell. -----Original Message----- From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] Sent: Wednesday, April 20, 2016 2:46 AM To: Mike Bishop <Michael.Bishop@microsoft.com> Cc: Michael Kaufmann <mail@michael-kaufmann.ch>; ietf-http-wg@w3.org Subject: Re: Is the response header "Upgrade: h2" allowed when TLS is used? If backport gets the votes, next Apache httpd release will no longer carry h2 in an Upgrade: announcement. Thanks for your time. -Stefan PS. Which still does not make sense to me, but seems to be what the specification says... > Am 19.04.2016 um 23:47 schrieb Mike Bishop <Michael.Bishop@microsoft.com>: > > That would seem reasonable. Hypothetically, a server could attempt RFC 2817-style Upgrade to TLS and then select "h2" as the ALPN token during the TLS handshake. A logical flow for carrying the initial request into the h2 context would look a lot like that for h2c -- stream 1 is half-closed and already "contains" the client's initial request. However, that still wouldn't use an "h2" Upgrade token and isn't actually defined anywhere. > > "Upgrade: h2c" or offer Alt-Svc if you want to switch to HTTP/2 on a different, encrypted connection. > > -----Original Message----- > From: Michael Kaufmann [mailto:mail@michael-kaufmann.ch] > Sent: Tuesday, April 19, 2016 2:30 PM > To: ietf-http-wg@w3.org > Subject: Re: Is the response header "Upgrade: h2" allowed when TLS is used? > > Zitat von Amos Jeffries <squid3@treenet.co.nz>: > >> On 20/04/2016 4:07 a.m., Cory Benfield wrote: >>> >>> Heh, I missed that. With that note, then, I’d say that Apache should >>> stop putting h2 in the Upgrade header on a TLS-using connection >>> *unless* it believes that connection is for a HTTP-schemed URL, when >>> it should put h2c. >>> >>> Cory >>> >> >> >> I think you are all overlooking the basic details: >> >> * RFC 7540 does not govern HTTP/1.1 connections, even TLS ones. >> >> * RFC 7540 section 3.2 is about negotiating http:// URLs over non-TLS >> connections. >> >> >> When the client has negotiated for HTTP/1.1 over TLS to happen (aka >> HTTPS). It is appropriate to Upgrade:h2. Since RFC 723x applies. >> >> >> But when the client negotiates h2c to happen. It is forbidden from >> using >> Upgrade:h2 to get to h2. Avoiding the issues Upgrade would have with >> only one-way encryption for the message pair. >> >> Note that h2c is also forbidden from being used in ALPN by section 3.3. >> So there is no valid way to be using TLS for h2c in the first place. >> >> If one is already using h2 it is pointless to Upgrade:h2. >> > > I have just realized that RFC 7540 registers the "h2c" upgrade token > (section 11.8) but it does NOT register an "h2" upgrade token. (it > also registers the identification strings "h2" and "h2c" for ALPN in > section 11.1, but that is a different thing) > > The upgrade token "h2" probably does not exist according to the RFCs. > It is also not mentioned here: > http://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-token > s.xhtml > > So when using TLS, servers should not send "Upgrade: h2" because "h2" > is an undefined upgrade token. And also when using TLS, servers should not send "Upgrade: h2c" because h2c means "HTTP/2 using cleartext TCP", and a connection that uses TLS cannot be "upgraded" to a connection that does not use TLS. > > Do you agree...? > > Regards, > Michael > >
Received on Wednesday, 20 April 2016 17:01:45 UTC