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

["Roy T. Fielding" <[e-mail]>]

>> Am 19.04.2016 um 23:47 schrieb Mike Bishop <[e-mail]>:
>> 
>> 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:[e-mail]] 
>> Sent: Tuesday, April 19, 2016 2:30 PM
>> To: [e-mail]
>> Subject: Re: Is the response header "Upgrade: h2" allowed when TLS is used?
>> 
>> 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.

It can be interpreted that way, yes.

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

Well, no, h2 as a token presumes a completely secured TLS connection.  How you get
there is left up to the client and server to negotiate.

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

No, there is just no way defined by RFC7540. That doesn't mean it can't be implemented.
TLS is just a connection.

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

No, that presumes only registered tokens can be used.  HTTP/1.1 is not so limited.

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

No, because TLS is just a connection.  For example, it might be opportunistic TLS.
Or it might be a configured tunnel over TLS or SSH of which the HTTP level is unaware.

It is better to think of the tokens as a protocol of their own, rather than a reference
to a specific protocol with the same name (or not, in the case of h2).  In other words,
the "h2c" token has a defined way of being interpreted that might result in some set of
actions by the recipient to reach some other state.  Likewise for h2, even though its
interpretation has not been defined by the registry.

BTW, if you send "Upgrade: HTTP/2.0, TLS", its interpretation is defined by RFC7230.


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <http://www.adobe.com/>