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

[Michael Kaufmann <[e-mail]>]

Zitat von Amos Jeffries <[e-mail]>:

> 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-tokens.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