RE: Is the response header "Upgrade: h2" allowed when TLS is used?

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