> On Apr 20, 2016, at 4:29 AM, Stefan Eissing <stefan.eiss...@greenbytes.de>
> wrote:
>
>>
>> Am 20.04.2016 um 13:16 schrieb Yann Ylavic <ylavic....@gmail.com>:
>>
>> On Wed, Apr 20, 2016 at 1:09 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
>>> On Wed, Apr 20, 2016 at 11:25 AM, Stefan Eissing
>>> <stefan.eiss...@greenbytes.de> wrote:
>>>> Done in r1740075.
>>>>
>>>> I was thinking of a nicer solution, but that involved inventing new hooks
>>>> which seems not worth it.
>>>>
>>>> Since this area of protocol negotiation has already been talked about in
>>>> regard to TLS upgrades
>>>> and websockets, I do not want to invest in the current way of handling
>>>> this too much time.
>>>
>>> I really don't see why we couldn't upgrade to h2 from "http:" (not
>>> "https:" since ALPN did not take place already, or would have done
>>> it).
>>> ISTM that "Upgrade: h2" could be valid in response to a (plain) HTTP/1
>>> request, and the client could upgrade from there...
>>
>> More on this and Michael's quote of RFC 7540 ("A server MUST ignore an
>> "h2" token...").
>> An HTTP/2 server must indeed ignore the inner HTTP/1 request's
>> "Upgrade: h2" header since it's RFC states it, but and HTTP/1 server
>> (AFAICT) is not concerned by this RFC, and should not...
>
> Totally agree. And, although untested, in principle we would upgrade
> such a request, as our protocol negotiation framework is somewhat agnostic
> to which RFC can leak water farther than others.
I think we need to be clear when the RFC applies and when it does not.
For example, ANY requirement in the RFC about TLS must be ignored by our
code (but not our default config) because we intend to implement h2c over
anything within some environments. The RFC was written for the sole
use case of browsers making requests over the open Internet and we should
expect to deviate where its requirements are clearly for that context
rather than for technical reasons.
In any case, RFC7540 does allow an "Upgrade: h2" to be sent by the server
when the connection is already TLS; the fact that it actually means
"Upgrade: HTTP/2.0, TLS" can be handled as we see fit. There is no
need to be pedantic because we are doing HTTP/1.1 at that point, not h2.
If there is a problem with sending h2 or h2c in a non-TLS response, then
we can send
Upgrade: HTTP/2.0
instead (with or without the TLS, depending on how we are configured).
It says the same thing as h2c (or h2), as far as HTTP/1.x is concerned.
If that is still a problem with NodeJS, then we should have a conditional
workaround that is limited to the NodeJS client string (including its version);
we cannot allow broken clients to define the protocol in the long term.
Cheers,
....Roy
