Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: "Upgrade: h2" header for HTTP/1.1 via TLS (Bug 59311)
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <CACsi251+a9oKxx5avZx8GUns-iFwG4U1=o4o9qBomVCMt6=zoA@mail.gmail.com>
Date: Thu, 16 Jun 2016 14:00:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <68D545A1-68D4-442A-B286-5B236FB4AA01@greenbytes.de>
References: <20160419144710.Horde.fEyz_FnLQe5b-8glHPB0ySG@webmail.michael-kaufmann.ch> <CACsi252Zc8SqBbW+gPUngUiZWX9gV6P0KRNQEj0ooQ6ebHS0wQ@mail.gmail.com> <CE051216-EAA0-4ED5-8132-90EEF2BB021A@greenbytes.de> <CACsi251ncQCkB+dM-Gd9k4HP8uppo+5Ke+DPxAAhh99a6kN8iA@mail.gmail.com> <20160609225218.Horde.El_vB3E_HAGC8AX_DHoPc1R@webmail.michael-kaufmann.ch> <CACsi25341fFid-yTu31H369qQdCnUp7Ti1V+T5iPm3iksZO=Xw@mail.gmail.com> <B388B626-2EC2-4F67-B418-98F8DF8D3968@greenbytes.de> <CACsi251E_DoG-xoHL-Y5bKFWwNouDGZYbadyemB2TCfFbNUH6g@mail.gmail.com> <CACsi253__TGTp7F1=o0_bhz7mV_6ryJra=kbwuM8x-SSEfKd=w@mail.gmail.com> <5761D770.1080409@gmail.com> <7FBF986F-55AC-44B8-9079-84E3EB14C1DB@greenbytes.de> <CACsi251+a9oKxx5avZx8GUns-iFwG4U1=o4o9qBomVCMt6=zoA@mail.gmail.com>
To: dev@httpd.apache.org
archived-at: Thu, 16 Jun 2016 12:00:47 -0000

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>:
>=20
>=20
> 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.
>=20
> I agree this is the workaround for broken clients.  Using SetEnvIf, =
this can even be conditional on said broken clients.
>=20
> It is a sufficient workaround for 2.4.21.
>=20
> >    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
>=20
> 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.
>=20
> Perhaps a 'once' optimization could be added, to suppress on =
subsequent responses without the upgrade required status.
>=20
> This can certainly be deferred for 2.4.22.
>=20
> > 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.
>=20
> > 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.
>=20
> Agreed there is no urgency to doing either right at this moment, and =
note there are other schemes afoot...
>=20
> https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun/0298.html
>=20
> > 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.
>=20
> Agreed, I set that down and need to pick this back up in the immediate =
future, but not prior to 2.4.21...