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 <[email protected]>:
>
> 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
