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