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 12:00:45 GMT
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 <wrowe@rowe-clan.net>:
> 
> 
> On Jun 16, 2016 3:30 AM, "Stefan Eissing" <stefan.eissing@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...


Mime
View raw message