mod_http2 in /trunk now checks for a minimum nghttp2 version of 1.2.1 and #ifdefs code accordingly. Will backport to 2.4.x later together with other changes.
> Am 04.12.2015 um 09:19 schrieb William A Rowe Jr <wr...@rowe-clan.net>: > > On Wed, Dec 2, 2015 at 5:24 PM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > I put it on my TODO for friday, maybe I can conf/ifdef around it without too > much pain. > > Am 02.12.2015 um 23:16 schrieb William A Rowe Jr <wr...@rowe-clan.net>: > >> On Wed, Dec 2, 2015 at 3:06 PM, Reindl Harald <h.rei...@thelounge.net> wrote: >> >> Am 02.12.2015 um 21:53 schrieb William A Rowe Jr: >> It seems nghttp2 1.2.1 is no longer supported? If we are missing an >> #include, let's fix, and if we want to drop support, that's fine too, but >> ./configure needs to reject the invalid version of nghttp2. >> >> Note that we couldn't normally drop support for an older nghttp2, >> but mod_http2 was clearly tagged as experimental, so packagers >> who pick it up and enable it are responsible for keeping up. >> >> Reindl identifies one distribution that will be immediately burned >> by picking up 2.4.18 without also bumping nghttp2 to 1.3 or later... >> >> This is the version shipping on FC22... >> nghttp2.x86_64 1.2.1-1.fc22 >> >> unconfirmed >> >> [builduser@buildserver:~]$ rpm -q httpd >> httpd-2.4.17-2.fc22.20151012.rh.x86_64 >> >> We are on two different pages, I'm speaking of branches/2.4.x at 2.4.18-dev, >> based on current backports. I wasn't commenting on the previous release. >> > > I'm glad you can look at this over the weekend. I am just fine with > demanding a different version of nghttp2, or deciding on a baseline > and then offering "more correct" functionality on another rev level. > I expect most of dev@httpd will agree since we declared this all > experimental. > > Off topic, can you explain why core Upgrade requests are dealt with > as a 'handler', since they are protocol layer details? the "core upgrade" > ''handler'' is sort of oxymoronic, since upgrade is one protocol to another > in the course of a specific received request, and it the implementation > appears to break all http rfcs? There is no way to incorporate the > prior/initial TLS/n.n upgrade, per spec, in this current schema as > implemented. > > I hope we can revert/fix/enhance prior to 2.4.18 'working' release? > > Cheers, > > Bill > >
