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

Thanks, Mike. I do not want to fight windmills. It is more an itch that our implementation reads a bit quirky in this case and cohesion ist lost. But you are right: it is what it is. 

> Am 20.04.2016 um 19:01 schrieb Mike Bishop <Michael.Bishop@microsoft.com>:
> 
> 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 18:13:38 UTC