Totally agree. This is all post 2.4.21 with the "Header unset Upgrade" available as workaround for 2.4.21.
> Am 16.06.2016 um 13:56 schrieb William A Rowe Jr <wr...@rowe-clan.net>: > > > On Jun 16, 2016 3:30 AM, "Stefan Eissing" <stefan.eiss...@greenbytes.de> > wrote: > > > > 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. > > I agree this is the workaround for broken clients. Using SetEnvIf, this can > even be conditional on said broken clients. > > It is a sufficient workaround for 2.4.21. > > > 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 > > One other ... right now your logic announces once, but HTTP/1 is stateless. > The upgrade advertising header should generally be presented with each > applicable response. > > Perhaps a 'once' optimization could be added, to suppress on subsequent > responses without the upgrade required status. > > This can certainly be deferred for 2.4.22. > > > 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. > > Agreed there is no urgency to doing either right at this moment, and note > there are other schemes afoot... > > https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun/0298.html > > > 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. > > Agreed, I set that down and need to pick this back up in the immediate > future, but not prior to 2.4.21...
