httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)
Date Thu, 16 Jun 2016 08:30:27 GMT
There are three things to address, one core related and one HTTP/2 related:

1. The whole discussion arose, because there are clients that seriously choke on
   *any* Upgrade: response header. No matter what tokens it contains. Those *can* now
   be addressed via mod_header with a "Header unset Upgrade" directive.
   Since Upgrade: is a core feature, it should maybe better be a core directive, such as

     ProtocolsHttpUpgradeAnnounce on|off         # make no announce in a response header
     ProtocolsHttpUpgrade on|off                 # make no http Upgrade: at all

2. What kind of HTTP/1.1 Upgrade: paths we want to implement.
   - 'h2c' on a cleartext connection, I assume, is desired
   - 'h2' on a cleartext connection, I do not see a use case for. Same as 'TLS/1.x, HTTP/2'.
It might be interesting to debate which is more according to which spec, but I do not plan
to participate in that.
   - 'h2' on a TLS connection. This is currently supported, configured off by default. So
we do conform to RFC7540, but one can configure a TLS HTTP/1.1 -> HTTP/2 upgrade path if
one so desires.

As to the discussion of 'HTTP/2' or 'HTTP/2.0' vs. 'h2' on TLS connections, we could also
decide to support that. I am +-0 on this. I think 'h2' is immediately clear to anyone that
has read RFC7540 at least once. Regardless of it being only registered for ALPN.

3. The whole 'TLS/x.x, other-id' upgrade dance on cleartext connections has been discussed
months ago. We should discuss how we address this in the core protocols_propose/switch API
that has been marked experimental and needs to be re-visited after the experiences of the
last months. Also, the requirements from Jacob in regard to WebSocket Upgrade should be factored
in.

-Stefan


> Am 16.06.2016 um 00:32 schrieb Jacob Champion <champion.p@gmail.com>:
> 
> On 06/15/2016 01:32 PM, William A Rowe Jr wrote:
>> It seems to me that we -can- implement
>> Connection: Upgrade
>> Upgrade: h2
>> on a plaintext connection, which is simply shorthand for Upgrade:
>> TLS/1.x, HTTP/2
>> where the TLS connection *must* handshake with the ALPN token 'h2' (the 102
>> Switching Protocols would be followed by a TLS HELO), and that
>> restricted set
>> of TLS protocols and ciphers acceptable to the HTTP/2 protocol.
> 
> It may be *allowed* (I'm still mulling it over in my head; it seems to me to be a substantial
stretching of the spirit of the Upgrade dance)... but I would seriously hope that httpd *doesn't*
decide to do this. At least not without a really good client use case first. Additional fragmentation
of the handshake types increases complexity and attack surface.
> 
> I am very curious about Roy's assertion (AIUI) that the 'HTTP/2.0' upgrade token is implicitly
defined by the existence of RFC 7540. What are its semantics? Are they equivalent to those
of the 'h2c' token?
> 
> (I understand that RFC 7230 *registers* all tokens of the form 'HTTP/m.n'. That is different
to me than saying, "If someone in the future creates an RFC called HTTPv4, all 'HTTP/4.x'
tokens are automatically defined by that specification, whether they know it or not.")
> 
> --Jacob


Mime
View raw message