httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)
Date Thu, 16 Jun 2016 11:56:49 GMT
On Jun 16, 2016 3:30 AM, "Stefan Eissing" <>
> There are three things to address, one core related and one HTTP/2
> 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...

> 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

Agreed, I set that down and need to pick this back up in the immediate
future, but not prior to 2.4.21...

View raw message