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: Broken 2.4 ./configure
Date Fri, 04 Dec 2015 11:39:34 GMT
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 <wrowe@rowe-clan.net>:
> 
> On Wed, Dec 2, 2015 at 5:24 PM, Stefan Eissing <stefan.eissing@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 <wrowe@rowe-clan.net>:
> 
>> On Wed, Dec 2, 2015 at 3:06 PM, Reindl Harald <h.reindl@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
> 
> 


Mime
View raw message