Re: The drive for 2.4.26

[Jim Jagielski]

There was a delay in doing the T due to an issue that
was being investigated. This looks resolved now. With that,
I plan on doing a T& today at ~1:30pm (Eastern) unless someone
else wishes to RM.

Re: The drive for 2.4.26

[Jim Jagielski]

Still looking at a T today... I will RM unless someone else
would like to do so!

Re: The drive for 2.4.26

[William A Rowe Jr]

On Thu, Jun 8, 2017 at 11:07 AM, Jim Jagielski  wrote:
> Perfect... I propose a T on Monday... comments?

+1. Many will have noticed already, but apr 1.6.2 and apr-util-1.6.0 vote
threads were just spawned to be tallied 13:00 UTC Monday.

Re: The drive for 2.4.26

[Jim Jagielski]

Perfect... I propose a T on Monday... comments?

> On Jun 6, 2017, at 5:23 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> 
> wrote:
> 
> Backported. Will also release v1.10.6 on github shortly.
> 
>> Am 06.06.2017 um 10:53 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>:
>> 
>>> 
>>> Am 06.06.2017 um 10:45 schrieb Plüm, Rüdiger, Vodafone Group 
>>> <ruediger.pl...@vodafone.com>:
>>> 
>>> 
>>> 
>>>> -Ursprüngliche Nachricht-
>>>> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
>>>> Gesendet: Dienstag, 6. Juni 2017 10:40
>>>> An: dev@httpd.apache.org
>>>> Betreff: Re: The drive for 2.4.26
>>>> 
>>>> Proposed the patch as fix, since we did not see the behaviour pop up
>>>> again over the last days at Steffen's system.
>>>> 
>>>> I assume the RTC is in place now.
>>> 
>>> My personal opinion: Only after 2.4.26 is released. So from my personal 
>>> point of view you can go ahead backporting.
>>> Others may see this differently.
>> 
>> I shall use the time our US friends are still slumbering on to back port the 
>> change, taking your statement as an excuse. :-P
>> 
>> -Stefan
>> 
>>> 
>>> Regards
>>> 
>>> Rüdiger
>>> 
>>>> 
>>>> -Stefan
>>>> 
>>>>> Am 06.06.2017 um 09:26 schrieb Stefan Eissing
>>>> <stefan.eiss...@greenbytes.de>:
>>>>> 
>>>>> I made a patch on Friday evening for Steffen's system where the
>>>> behaviour happens. Hope to hear back from him today.
>>>>> 
>>>>> -Stefan
>>>>> 
>>>>>> Am 06.06.2017 um 03:12 schrieb Eric Covener <cove...@gmail.com>:
>>>>>> 
>>>>>> On Tue, May 30, 2017 at 9:12 AM, Stefan Eissing
>>>>>> <stefan.eiss...@greenbytes.de> wrote:
>>>>>>> I have one report of a CPU busy loop that seems to only happen on
>>>> the last 3 changes in mod_http2. Steffen is currently testing if a
>>>> feature disable solves the problem and thus points to the cause. I hope
>>>> to hear from him tomorrow sometime during the day if that addresses the
>>>> issue or not.
>>>>>>> 
>>>>>>> Otherwise I am hesitant to make any more changes from my side and
>>>> hope we can go forward with a release.
>>>>>> 
>>>>>> 
>>>>>> Anything on this?
>>>>>> 
>>>>>> --
>>>>>> Eric Covener
>>>>>> cove...@gmail.com
> 

Re: The drive for 2.4.26

[Stefan Eissing]

Backported. Will also release v1.10.6 on github shortly.

> Am 06.06.2017 um 10:53 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>:
> 
>> 
>> Am 06.06.2017 um 10:45 schrieb Plüm, Rüdiger, Vodafone Group 
>> <ruediger.pl...@vodafone.com>:
>> 
>> 
>> 
>>> -Ursprüngliche Nachricht-
>>> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
>>> Gesendet: Dienstag, 6. Juni 2017 10:40
>>> An: dev@httpd.apache.org
>>> Betreff: Re: The drive for 2.4.26
>>> 
>>> Proposed the patch as fix, since we did not see the behaviour pop up
>>> again over the last days at Steffen's system.
>>> 
>>> I assume the RTC is in place now.
>> 
>> My personal opinion: Only after 2.4.26 is released. So from my personal 
>> point of view you can go ahead backporting.
>> Others may see this differently.
> 
> I shall use the time our US friends are still slumbering on to back port the 
> change, taking your statement as an excuse. :-P
> 
> -Stefan
> 
>> 
>> Regards
>> 
>> Rüdiger
>> 
>>> 
>>> -Stefan
>>> 
>>>> Am 06.06.2017 um 09:26 schrieb Stefan Eissing
>>> <stefan.eiss...@greenbytes.de>:
>>>> 
>>>> I made a patch on Friday evening for Steffen's system where the
>>> behaviour happens. Hope to hear back from him today.
>>>> 
>>>> -Stefan
>>>> 
>>>>> Am 06.06.2017 um 03:12 schrieb Eric Covener <cove...@gmail.com>:
>>>>> 
>>>>> On Tue, May 30, 2017 at 9:12 AM, Stefan Eissing
>>>>> <stefan.eiss...@greenbytes.de> wrote:
>>>>>> I have one report of a CPU busy loop that seems to only happen on
>>> the last 3 changes in mod_http2. Steffen is currently testing if a
>>> feature disable solves the problem and thus points to the cause. I hope
>>> to hear from him tomorrow sometime during the day if that addresses the
>>> issue or not.
>>>>>> 
>>>>>> Otherwise I am hesitant to make any more changes from my side and
>>> hope we can go forward with a release.
>>>>> 
>>>>> 
>>>>> Anything on this?
>>>>> 
>>>>> --
>>>>> Eric Covener
>>>>> cove...@gmail.com

Re: The drive for 2.4.26

[Stefan Eissing]

> Am 06.06.2017 um 10:45 schrieb Plüm, Rüdiger, Vodafone Group 
> <ruediger.pl...@vodafone.com>:
> 
> 
> 
>> -Ursprüngliche Nachricht-
>> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
>> Gesendet: Dienstag, 6. Juni 2017 10:40
>> An: dev@httpd.apache.org
>> Betreff: Re: The drive for 2.4.26
>> 
>> Proposed the patch as fix, since we did not see the behaviour pop up
>> again over the last days at Steffen's system.
>> 
>> I assume the RTC is in place now.
> 
> My personal opinion: Only after 2.4.26 is released. So from my personal point 
> of view you can go ahead backporting.
> Others may see this differently.

I shall use the time our US friends are still slumbering on to back port the 
change, taking your statement as an excuse. :-P

-Stefan

> 
> Regards
> 
> Rüdiger
> 
>> 
>> -Stefan
>> 
>>> Am 06.06.2017 um 09:26 schrieb Stefan Eissing
>> <stefan.eiss...@greenbytes.de>:
>>> 
>>> I made a patch on Friday evening for Steffen's system where the
>> behaviour happens. Hope to hear back from him today.
>>> 
>>> -Stefan
>>> 
>>>> Am 06.06.2017 um 03:12 schrieb Eric Covener <cove...@gmail.com>:
>>>> 
>>>> On Tue, May 30, 2017 at 9:12 AM, Stefan Eissing
>>>> <stefan.eiss...@greenbytes.de> wrote:
>>>>> I have one report of a CPU busy loop that seems to only happen on
>> the last 3 changes in mod_http2. Steffen is currently testing if a
>> feature disable solves the problem and thus points to the cause. I hope
>> to hear from him tomorrow sometime during the day if that addresses the
>> issue or not.
>>>>> 
>>>>> Otherwise I am hesitant to make any more changes from my side and
>> hope we can go forward with a release.
>>>> 
>>>> 
>>>> Anything on this?
>>>> 
>>>> --
>>>> Eric Covener
>>>> cove...@gmail.com
>>> 
> 

AW: The drive for 2.4.26

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Gesendet: Dienstag, 6. Juni 2017 10:40
> An: dev@httpd.apache.org
> Betreff: Re: The drive for 2.4.26
> 
> Proposed the patch as fix, since we did not see the behaviour pop up
> again over the last days at Steffen's system.
> 
> I assume the RTC is in place now.

My personal opinion: Only after 2.4.26 is released. So from my personal point 
of view you can go ahead backporting.
Others may see this differently.

Regards

Rüdiger

> 
> -Stefan
> 
> > Am 06.06.2017 um 09:26 schrieb Stefan Eissing
> <stefan.eiss...@greenbytes.de>:
> >
> > I made a patch on Friday evening for Steffen's system where the
> behaviour happens. Hope to hear back from him today.
> >
> > -Stefan
> >
> >> Am 06.06.2017 um 03:12 schrieb Eric Covener <cove...@gmail.com>:
> >>
> >> On Tue, May 30, 2017 at 9:12 AM, Stefan Eissing
> >> <stefan.eiss...@greenbytes.de> wrote:
> >>> I have one report of a CPU busy loop that seems to only happen on
> the last 3 changes in mod_http2. Steffen is currently testing if a
> feature disable solves the problem and thus points to the cause. I hope
> to hear from him tomorrow sometime during the day if that addresses the
> issue or not.
> >>>
> >>> Otherwise I am hesitant to make any more changes from my side and
> hope we can go forward with a release.
> >>
> >>
> >> Anything on this?
> >>
> >> --
> >> Eric Covener
> >> cove...@gmail.com
> >

Re: The drive for 2.4.26

[Stefan Eissing]

Proposed the patch as fix, since we did not see the behaviour pop up again over 
the last days at Steffen's system.
 
I assume the RTC is in place now.

-Stefan

> Am 06.06.2017 um 09:26 schrieb Stefan Eissing :
> 
> I made a patch on Friday evening for Steffen's system where the behaviour 
> happens. Hope to hear back from him today.
> 
> -Stefan
> 
>> Am 06.06.2017 um 03:12 schrieb Eric Covener :
>> 
>> On Tue, May 30, 2017 at 9:12 AM, Stefan Eissing
>>  wrote:
>>> I have one report of a CPU busy loop that seems to only happen on the last 
>>> 3 changes in mod_http2. Steffen is currently testing if a feature disable 
>>> solves the problem and thus points to the cause. I hope to hear from him 
>>> tomorrow sometime during the day if that addresses the issue or not.
>>> 
>>> Otherwise I am hesitant to make any more changes from my side and hope we 
>>> can go forward with a release.
>> 
>> 
>> Anything on this?
>> 
>> -- 
>> Eric Covener
>> cove...@gmail.com
> 

Re: The drive for 2.4.26

[Stefan Eissing]

I made a patch on Friday evening for Steffen's system where the behaviour 
happens. Hope to hear back from him today.

-Stefan

> Am 06.06.2017 um 03:12 schrieb Eric Covener :
> 
> On Tue, May 30, 2017 at 9:12 AM, Stefan Eissing
>  wrote:
>> I have one report of a CPU busy loop that seems to only happen on the last 3 
>> changes in mod_http2. Steffen is currently testing if a feature disable 
>> solves the problem and thus points to the cause. I hope to hear from him 
>> tomorrow sometime during the day if that addresses the issue or not.
>> 
>> Otherwise I am hesitant to make any more changes from my side and hope we 
>> can go forward with a release.
> 
> 
> Anything on this?
> 
> -- 
> Eric Covener
> cove...@gmail.com

Re: The drive for 2.4.26

[Eric Covener]

On Tue, May 30, 2017 at 9:12 AM, Stefan Eissing
 wrote:
> I have one report of a CPU busy loop that seems to only happen on the last 3 
> changes in mod_http2. Steffen is currently testing if a feature disable 
> solves the problem and thus points to the cause. I hope to hear from him 
> tomorrow sometime during the day if that addresses the issue or not.
>
> Otherwise I am hesitant to make any more changes from my side and hope we can 
> go forward with a release.


Anything on this?

-- 
Eric Covener
cove...@gmail.com

Re: The drive for 2.4.26

[William A Rowe Jr]

The suggestion is to push out any 2.4 release indefinately for an
experimental feature which is promoted in another thread for promotion
to a GA designation?

Just a sanity check of my sense of irony :)

On Wed, May 31, 2017 at 6:59 AM, Jim Jagielski  wrote:
> I think we should wait on a T to resolve this issue...
>
>> On May 30, 2017, at 9:12 AM, Stefan Eissing  
>> wrote:
>>
>> I have one report of a CPU busy loop that seems to only happen on the last 3 
>> changes in mod_http2. Steffen is currently testing if a feature disable 
>> solves the problem and thus points to the cause. I hope to hear from him 
>> tomorrow sometime during the day if that addresses the issue or not.

Re: The drive for 2.4.26

[Jim Jagielski]

I think we should wait on a T to resolve this issue...

> On May 30, 2017, at 9:12 AM, Stefan Eissing  
> wrote:
> 
> I have one report of a CPU busy loop that seems to only happen on the last 3 
> changes in mod_http2. Steffen is currently testing if a feature disable 
> solves the problem and thus points to the cause. I hope to hear from him 
> tomorrow sometime during the day if that addresses the issue or not.
> 

Re: The drive for 2.4.26

[William A Rowe Jr]

On Tue, May 30, 2017 at 4:21 PM, Jacob Champion  wrote:
> On 05/29/2017 10:52 PM, Jan Ehrhardt wrote:
>>
>> Jan Ehrhardt in gmane.comp.apache.devel (Tue, 30 May 2017 07:13:41
>> +0200):
>>>
>>> Steffen in gmane.comp.apache.devel (Mon, 29 May 2017 15:42:46 +0200):
>>>
 Cmake is now Windows only, is that the goal ?
>>>
>>>
>>> In what way is it Windows only?
>>
>> To answer my own question: because of the use of specific Windows only
>> extensions like .lib and names like libaprutil-1.lib. Many (all?) of
>> these can be overridden in the CMake config options, so there is a
>> chance it already works on other OS's.
>
> I would be surprised if it did; I thought the main goal of the CMake build
> was to provide an alternative to the .dsp files, for Windows only. See
> README.cmake.

Speaking to httpd only; we have logic in our autoconf/config.m4 files to
toggle specific modules, this logic hasn't been propagated to cmake.

The cmake files are referencing win32-specific modules and win32 mpm
alone, and have no mechanism to perform the many other autoconf
tests yet which can be "defaulted" to their expected win32 answers.
(Those answers may no longer be the best answer under the most
recent C99/C11/Posix enhancements.) Configure-time tests are
needed to resolve the questions/config flags.

Speaking to APR only, it's also hunting the apr/feature/win32/*.c
and some fallback apr/feature/unix/*.c fallback implementations.
Also missing feature tests and using win32-specific assumptions.
Obviously wrong, but simpler to fix than what I described above
at our project here.

Re: The drive for 2.4.26

[William A Rowe Jr]

On Mon, May 29, 2017 at 8:42 AM, Steffen  wrote:
>
> Btw.
> Cmake is now Windows only, is that the goal ?

No; however the autoconf works so well on such a broad assortment
of Unix distributions that we haven't found a lot of motivation to fully
instrument the cmake lists for unix flavors. It's an obvious win if we can
move all OS2 and Netware logic to cmake or simply drop architectures
moving beyond 2.4.x releases. But I know little of the OS2 and Netware
support from the cmake project.

I'll likely start at the APR project in terms of instrumenting CMake logic
for Unix. While it's not "strictly necessary", it allows better testing of
the cmake logic while working in a unix environment, avoiding most
Windows breakage.

Re: The drive for 2.4.26

[Jacob Champion]

On 05/29/2017 10:52 PM, Jan Ehrhardt wrote:

Jan Ehrhardt in gmane.comp.apache.devel (Tue, 30 May 2017 07:13:41
+0200):

Steffen in gmane.comp.apache.devel (Mon, 29 May 2017 15:42:46 +0200):


Cmake is now Windows only, is that the goal ?


In what way is it Windows only?


To answer my own question: because of the use of specific Windows only
extensions like .lib and names like libaprutil-1.lib. Many (all?) of
these can be overridden in the CMake config options, so there is a
chance it already works on other OS's.


I would be surprised if it did; I thought the main goal of the CMake 
build was to provide an alternative to the .dsp files, for Windows only. 
See README.cmake.


--Jacob

Re: The drive for 2.4.26

[Steffen]

Still not working mod_proxy_http2 with larger responses. 


>>> Still wrong with
>>> ProxyPass / h2c://127.0.0.1:80/
>>> ProxyPassReverse / http://127.0.0.1:80/

>>> Latest/former answer from Stefan was on this error was:

>>> Thanks for testing. As I read your logs, the mod_proxy_http2 does not send 
>>> WINDOW_UPDATEs to the upstream server. That means its flow control window 
>>> of 
>>> 32KB gets exhausted and it stops sending. Everyone is then waiting.




> Op 30 mei 2017 om 14:57 heeft Jim Jagielski  het volgende 
> geschreven:
> 
> It looks like all the "easy and safe" backports have been
> submitted and then committed. I am hesitant to stir things
> up anymore and think that this week is our luck week for a
> T of 2.4.26.
> 
> Comments? Feedback?

r1792092 (Was: Re: The drive for 2.4.26)

[Jim Jagielski]

Eric just noted that one viable backport hasn't been proposed
yet... Jean-Frederic, can you confirm that r1792092 is something
you'd like to see in 2.4.x? Other than the field addition to the
struct, the change looks v. self-contained.

Re: The drive for 2.4.26

[Steffen]

Reminder:

No mod_session_crypto with apr & apr-util 1.5 and Openssl 1.1.0. 

With not released apr & apr-util 1.6 all fine.

> Op 30 mei 2017 om 14:57 heeft Jim Jagielski  het volgende 
> geschreven:
> 
> It looks like all the "easy and safe" backports have been
> submitted and then committed. I am hesitant to stir things
> up anymore and think that this week is our luck week for a
> T of 2.4.26.
> 
> Comments? Feedback?

Re: The drive for 2.4.26

[Yann Ylavic]

On Tue, May 30, 2017 at 3:01 PM, Eric Covener  wrote:
> On Tue, May 30, 2017 at 8:57 AM, Jim Jagielski  wrote:
>> It looks like all the "easy and safe" backports have been
>> submitted and then committed. I am hesitant to stir things
>> up anymore and think that this week is our luck week for a
>> T of 2.4.26.
>>
>> Comments? Feedback?
>
> +1, better to bank a release with what's in now.

+1, the backport proposals I added lately are quite intrusive and too
new in CHANGES for enough eyes to have reviewed them. Let's wait next
release for them.

Re: The drive for 2.4.26

[Stefan Eissing]

I have one report of a CPU busy loop that seems to only happen on the last 3 
changes in mod_http2. Steffen is currently testing if a feature disable solves 
the problem and thus points to the cause. I hope to hear from him tomorrow 
sometime during the day if that addresses the issue or not.

Otherwise I am hesitant to make any more changes from my side and hope we can 
go forward with a release.

-Stefan

> Am 30.05.2017 um 14:57 schrieb Jim Jagielski :
> 
> It looks like all the "easy and safe" backports have been
> submitted and then committed. I am hesitant to stir things
> up anymore and think that this week is our luck week for a
> T of 2.4.26.
> 
> Comments? Feedback?

Re: The drive for 2.4.26

[Eric Covener]

On Tue, May 30, 2017 at 8:57 AM, Jim Jagielski  wrote:
> It looks like all the "easy and safe" backports have been
> submitted and then committed. I am hesitant to stir things
> up anymore and think that this week is our luck week for a
> T of 2.4.26.
>
> Comments? Feedback?

+1, better to bank a release with what's in now.

Re: The drive for 2.4.26

[Jim Jagielski]

It looks like all the "easy and safe" backports have been
submitted and then committed. I am hesitant to stir things
up anymore and think that this week is our luck week for a
T of 2.4.26.

Comments? Feedback?

Re: The drive for 2.4.26

[Jan Ehrhardt]

Jan Ehrhardt in gmane.comp.apache.devel (Tue, 30 May 2017 07:13:41
+0200):
>Steffen in gmane.comp.apache.devel (Mon, 29 May 2017 15:42:46 +0200):
>
>> Cmake is now Windows only, is that the goal ?
>
>In what way is it Windows only?

To answer my own question: because of the use of specific Windows only
extensions like .lib and names like libaprutil-1.lib. Many (all?) of
these can be overridden in the CMake config options, so there is a
chance it already works on other OS's.
-- 
Jan

Re: The drive for 2.4.26

[Jan Ehrhardt]

Hi Rainer,

Rainer Jung in gmane.comp.apache.devel (Mon, 29 May 2017 15:00:45
+0200):
>What is this "slight modification"?

Steffen showed me that these modifications aren't needed with the CMake
option -DENABLE_MODULES=i
-- 
Jan

Re: The drive for 2.4.26

[Jan Ehrhardt]

Steffen in gmane.comp.apache.devel (Mon, 29 May 2017 15:42:46 +0200):
>Here only  :
>
>--   Modules not built:
>-- mod_socache_dc
>-- mod_charset_lite
>-- Configuring done
>
>Building with:
>cmake -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX=C:\Apache24 
>-DCMAKE_BUILD_TYPE=Release -DENABLE_MODULES=i -DINSTALL_MANUAL=OFF 
>-DINSTALL_PDB=OFF ..\..\src\httpd-2.4.26

Your -DENABLE_MODULES=i seems to do the same as my slight modifications.

Apart from setting some paths to the CMAKE_INSTALL_PREFIX and to some
include-dirs and libs my configure line was

CMake -G "Visual Studio 14 2015 Win64" -DAPU_HAVE_CRYPTO=1
-DAPR_HAS_LDAP=1 -DAPR_HAS_XLATE=1 -DINSTALL_MANUAL=0 -Wno-dev

Which leads to

-- Summary of feature detection:
--
-- LIBXML2_FOUND  : TRUE
-- LUA51_FOUND .. : TRUE
-- NGHTTP2_FOUND  : TRUE
-- OPENSSL_FOUND  : TRUE
-- ZLIB_FOUND ... : TRUE
-- BROTLI_FOUND . : TRUE
-- APR_HAS_LDAP . : TRUE
-- APR_HAS_XLATE  : TRUE
-- APU_HAVE_CRYPTO .. : TRUE

Note that I am creating a HTTPD.sln and *.vcxproj files.

> Cmake is now Windows only, is that the goal ?

In what way is it Windows only?
-- 
Jan

Re: The drive for 2.4.26

[Jan Ehrhardt]

Hi Rainer,

Rainer Jung in gmane.comp.apache.devel (Mon, 29 May 2017 15:00:45 +0200):
>Am 29.05.2017 um 10:54 schrieb Jan Ehrhardt:
>> If you really need one of these modules, with a slight modification of
>> CMakeLists.txt these can be built as well. Only real exception:
>> mod_socache_dc does not build at all, probably because of a missing
>> distcache dependency.
>
>What is this "slight modification"?

Replace +O+ 16 times with +I+:

--- CMakeListsOld.txt   2017-05-30 01:43:43.568577800 +0200
+++ CMakeLists.txt  2017-05-30 06:08:25.287100200 +0200
@@ -272,24 +272,24 @@
   "modules/dav/fs/mod_dav_fs+I+DAV provider for the filesystem."
   "modules/dav/lock/mod_dav_lock+I+DAV provider for generic locking"
   "modules/dav/main/mod_dav+I+WebDAV protocol handling."
-  "modules/debugging/mod_bucketeer+O+buckets manipulation filter.  Useful only 
for developers and testing purposes."
+  "modules/debugging/mod_bucketeer+I+buckets manipulation filter.  Useful only 
for developers and testing purposes."
   "modules/debugging/mod_dumpio+I+I/O dump filter"
-  "modules/echo/mod_echo+O+ECHO server"
-  "modules/examples/mod_case_filter+O+Example uppercase conversion filter"
-  "modules/examples/mod_case_filter_in+O+Example uppercase conversion input 
filter"
-  "modules/examples/mod_example_hooks+O+Example hook callback handler module"
-  "modules/examples/mod_example_ipc+O+Example of shared memory and mutex usage"
+  "modules/echo/mod_echo+I+ECHO server"
+  "modules/examples/mod_case_filter+I+Example uppercase conversion filter"
+  "modules/examples/mod_case_filter_in+I+Example uppercase conversion input 
filter"
+  "modules/examples/mod_example_hooks+I+Example hook callback handler module"
+  "modules/examples/mod_example_ipc+I+Example of shared memory and mutex usage"
   "modules/filters/mod_brotli+i+Brotli compression support"
   "modules/filters/mod_buffer+I+Filter Buffering"
   "modules/filters/mod_charset_lite+i+character set translation"
-  "modules/filters/mod_data+O+RFC2397 data encoder"
+  "modules/filters/mod_data+I+RFC2397 data encoder"
   "modules/filters/mod_deflate+i+Deflate transfer encoding support"
   "modules/filters/mod_ext_filter+I+external filter module"
   "modules/filters/mod_filter+A+Smart Filtering"
   "modules/filters/mod_include+I+Server Side Includes"
   "modules/filters/mod_proxy_html+i+Fix HTML Links in a Reverse Proxy"
   "modules/filters/mod_ratelimit+I+Output Bandwidth Limiting"
-  "modules/filters/mod_reflector+O+Reflect request through the output filter 
stack"
+  "modules/filters/mod_reflector+I+Reflect request through the output filter 
stack"
   "modules/filters/mod_reqtimeout+A+Limit time waiting for request from client"
   "modules/filters/mod_request+I+Request Body Filtering"
   "modules/filters/mod_sed+I+filter request and/or response bodies through sed"
@@ -317,12 +317,12 @@
   "modules/mappers/mod_speling+I+correct common URL misspellings"
   "modules/mappers/mod_userdir+I+mapping of requests to user-specific 
directories"
   "modules/mappers/mod_vhost_alias+I+mass virtual hosting module"
-  "modules/metadata/mod_cern_meta+O+CERN-type meta files"
+  "modules/metadata/mod_cern_meta+I+CERN-type meta files"
   "modules/metadata/mod_env+A+clearing/setting of ENV vars"
   "modules/metadata/mod_expires+I+Expires header control"
   "modules/metadata/mod_headers+A+HTTP header control"
-  "modules/metadata/mod_ident+O+RFC 1413 identity check"
-  "modules/metadata/mod_mime_magic+O+automagically determining MIME type"
+  "modules/metadata/mod_ident+I+RFC 1413 identity check"
+  "modules/metadata/mod_mime_magic+I+automagically determining MIME type"
   "modules/metadata/mod_remoteip+I+translate header contents to an apparent 
client remote_ip"
   "modules/metadata/mod_setenvif+A+basing ENV vars on headers"
   "modules/metadata/mod_unique_id+I+per-request unique ids"
@@ -351,11 +351,11 @@
   "modules/slotmem/mod_slotmem_plain+I+slotmem provider that uses plain memory"
   "modules/slotmem/mod_slotmem_shm+I+slotmem provider that uses shared memory"
   "modules/ssl/mod_ssl+i+SSL/TLS support"
-  "modules/test/mod_dialup+O+rate limits static files to dialup modem speeds"
-  "modules/test/mod_optional_fn_export+O+example optional function exporter"
-  "modules/test/mod_optional_fn_import+O+example optional function importer"
-  "modules/test/mod_optional_hook_export+O+example optional hook exporter"
-  "modules/test/mod_optional_hook_import+O+example optional hook importer"
+  "modules/test/mod_dialup+I+rate limits static files to dialup modem speeds"
+  "modules/test/mod_optional_fn_export+I+example optional function exporter"
+  "modules/test/mod_optional_fn_import+I+example optional function importer"
+  "modules/test/mod_optional_hook_export+I+example optional hook exporter"
+  "modules/test/mod_optional_hook_import+I+example optional hook importer"
 )
 
 # Track which modules actually built have APIs to link against.

-- 
Jan

Re: The drive for 2.4.26

[Steffen]

Here only  :


--   Modules not built:
-- mod_socache_dc
-- mod_charset_lite
-- Configuring done

Building with:
cmake -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX=C:\Apache24 
-DCMAKE_BUILD_TYPE=Release -DENABLE_MODULES=i -DINSTALL_MANUAL=OFF 
-DINSTALL_PDB=OFF ..\..\src\httpd-2.4.26



Btw.
Cmake is now Windows only, is that the goal ?
Is someone addressing the tbd's, bugs, limitations as noted in the 
(readme)cmake files ?

For me still not the way to make a distro.


On Monday 29/05/2017 at 15:01, Rainer Jung  wrote:

Hi Jan,

Am 29.05.2017 um 10:54 schrieb Jan Ehrhardt:


Rainer Jung in gmane.comp.apache.devel (Sun, 28 May 2017 23:20:35
+0200):


Due to quick votes from the team this has now been committed in 
r1796539

for 2.4.26.


Thanks. I checked woth the 2.4.x branch, built on Windows with
CMake/VC14 (plus APR 1.6 and OpenSSL 1.1.0) and the patch works OK.
CMake (on Windows) builds all modules now with the exception of these:

--   Modules not built:
-- mod_socache_dc
-- mod_bucketeer
-- mod_echo
-- mod_case_filter
-- mod_case_filter_in
-- mod_example_hooks
-- mod_example_ipc
-- mod_data
-- mod_reflector
-- mod_cern_meta
-- mod_ident
-- mod_mime_magic
-- mod_dialup
-- mod_optional_fn_export
-- mod_optional_fn_import
-- mod_optional_hook_export
-- mod_optional_hook_import
-- Configuring done

If you really need one of these modules, with a slight modification of
CMakeLists.txt these can be built as well. Only real exception:
mod_socache_dc does not build at all, probably because of a missing
distcache dependency.


What is this "slight modification"?

Regards,

Rainer

Re: The drive for 2.4.26

[Rainer Jung]

Hi Jan,

Am 29.05.2017 um 10:54 schrieb Jan Ehrhardt:

Rainer Jung in gmane.comp.apache.devel (Sun, 28 May 2017 23:20:35
+0200):

Due to quick votes from the team this has now been committed in r1796539
for 2.4.26.


Thanks. I checked woth the 2.4.x branch, built on Windows with
CMake/VC14 (plus APR 1.6 and OpenSSL 1.1.0) and the patch works OK.
CMake (on Windows) builds all modules now with the exception of these:

--   Modules not built:
-- mod_socache_dc
-- mod_bucketeer
-- mod_echo
-- mod_case_filter
-- mod_case_filter_in
-- mod_example_hooks
-- mod_example_ipc
-- mod_data
-- mod_reflector
-- mod_cern_meta
-- mod_ident
-- mod_mime_magic
-- mod_dialup
-- mod_optional_fn_export
-- mod_optional_fn_import
-- mod_optional_hook_export
-- mod_optional_hook_import
-- Configuring done

If you really need one of these modules, with a slight modification of
CMakeLists.txt these can be built as well. Only real exception:
mod_socache_dc does not build at all, probably because of a missing
distcache dependency.


What is this "slight modification"?

Regards,

Rainer

Re: The drive for 2.4.26

[Jan Ehrhardt]

Rainer Jung in gmane.comp.apache.devel (Sun, 28 May 2017 23:20:35
+0200):
>Due to quick votes from the team this has now been committed in r1796539 
>for 2.4.26.

Thanks. I checked woth the 2.4.x branch, built on Windows with
CMake/VC14 (plus APR 1.6 and OpenSSL 1.1.0) and the patch works OK.
CMake (on Windows) builds all modules now with the exception of these:

--   Modules not built:
-- mod_socache_dc
-- mod_bucketeer
-- mod_echo
-- mod_case_filter
-- mod_case_filter_in
-- mod_example_hooks
-- mod_example_ipc
-- mod_data
-- mod_reflector
-- mod_cern_meta
-- mod_ident
-- mod_mime_magic
-- mod_dialup
-- mod_optional_fn_export
-- mod_optional_fn_import
-- mod_optional_hook_export
-- mod_optional_hook_import
-- Configuring done

If you really need one of these modules, with a slight modification of
CMakeLists.txt these can be built as well. Only real exception:
mod_socache_dc does not build at all, probably because of a missing
distcache dependency.
-- 
Jan

Re: The drive for 2.4.26

[Rainer Jung]

Am 28.05.2017 um 16:16 schrieb Rainer Jung:

Am 28.05.2017 um 13:13 schrieb Jan Ehrhardt:

Rainer Jung in gmane.comp.apache.devel (Fri, 21 Apr 2017 00:29:38
+0200):

...

In addition I noticed the following glitch:

...

The "-m" option is independent of SSL use and should be handled outside
of "#ifdef USE_SSL".


This patch is not submitted. Any idea why? After all, the help text of
'ab' mentions ' -m method  Method name', but for instance '-m HEAD' has
no effect al all with 'ab', only with 'abs'.


Thanks for the reminder. Fixed in r1796493 for trunk and 2.4.x backport
proposal added.


Due to quick votes from the team this has now been committed in r1796539 
for 2.4.26.


Regards,

Rainer

Re: The drive for 2.4.26

[Yann Ylavic]

Hi,

On Sun, May 28, 2017 at 8:38 PM, Stefan Priebe - Profihost AG
 wrote:
> Hi Luca,
>
> Am 27.05.2017 um 09:10 schrieb Luca Toscano:
>> Hi Jim,
>>
>> 2017-05-25 14:23 GMT+02:00 Jim Jagielski > >:
>>
>> Until a proposal in in STATUS (and apologies if it is), its
>> suitability for 2.4.x is a big unknown.
>>
>>
>> you are completely right, afaik the last patch tested by Stefan Priebe
>> was https://bz.apache.org/bugzilla/attachment.cgi?id=34641=diff
>> (Stefan correct me if I am wrong).
>
> Yes that's right. Yann told something about a V8 coming soon but that's
> weeks ago. V7 seems to run fine. Currently running on nearly 2000 vms.

V7 proposed for backport to 2.4.x.

I called it v7.1 because of the following added hunk.
This removed code was 2.4 specific (not in trunk) and already handled
above (before the poll), so I don't see why we'd lock
g_timer_skiplist_mtx one more time here instead of waiting for the
next loop (and accurate timeout now thanks to wakeup).

@@ -1632,21 +1765,6 @@ static void * APR_THREAD_FUNC listener_thread(apr_
 break;
 }

-now = apr_time_now();
-apr_thread_mutex_lock(g_timer_skiplist_mtx);
-ep = apr_skiplist_peek(timer_skiplist);
-while (ep) {
-if (ep->when < now + EVENT_FUDGE_FACTOR) {
-apr_skiplist_pop(timer_skiplist, NULL);
-push_timer2worker(ep);
-}
-else {
-break;
-}
-ep = apr_skiplist_peek(timer_skiplist);
-}
-apr_thread_mutex_unlock(g_timer_skiplist_mtx);
-
 while (num) {
 pt = (listener_poll_type *) out_pfd->client_data;
 if (pt->type == PT_CSD) {

>
>> If I remember correctly it might be possible that some commits were not
>> necessary since they were made as a test to remove segfaults that we
>> discovered due to other things. I'll wait Yann's feedback but if anybody
>> wants to check the patch it would be really great.

V7 is all we need for now, the other changes relative to ptrans
allocator should be (and are now) addressed in mod_http2 (not really
needed for HTTP/1 handling).

Regarding v8, this is possibly an optimization to avoid external
locking when adding or removing events from the pollset, but it
introduces some race conditions which should be addressed before I
propose something.


Regards,
Yann.

Re: The drive for 2.4.26

[Stefan Priebe - Profihost AG]

Hi Luca,

Am 27.05.2017 um 09:10 schrieb Luca Toscano:
> Hi Jim,
> 
> 2017-05-25 14:23 GMT+02:00 Jim Jagielski  >:
> 
> Until a proposal in in STATUS (and apologies if it is), its
> suitability for 2.4.x is a big unknown.
> 
> 
> you are completely right, afaik the last patch tested by Stefan Priebe
> was https://bz.apache.org/bugzilla/attachment.cgi?id=34641=diff
> (Stefan correct me if I am wrong).

Yes that's right. Yann told something about a V8 coming soon but that's
weeks ago. V7 seems to run fine. Currently running on nearly 2000 vms.

> If I remember correctly it might be possible that some commits were not
> necessary since they were made as a test to remove segfaults that we
> discovered due to other things. I'll wait Yann's feedback but if anybody
> wants to check the patch it would be really great.
> 
> Thanks!
> 
> Luca 

Re: The drive for 2.4.26

[Rainer Jung]

Am 28.05.2017 um 13:13 schrieb Jan Ehrhardt:

Rainer Jung in gmane.comp.apache.devel (Fri, 21 Apr 2017 00:29:38
+0200):

Thanks for the analysis. So the following patch on trunk works for me
when using OpenSSL 1.0.1e (on Solaris 10):

Index: support/ab.c
===
--- support/ab.c(revision 1792155)
+++ support/ab.c(working copy)
@@ -2576,8 +2576,6 @@
 #else
 #if OPENSSL_VERSION_NUMBER < 0x1010L
 CRYPTO_malloc_init();
-#else
-OPENSSL_malloc_init();
 #endif
 #endif
 SSL_load_error_strings();


The same fix should apply for 2.4.x.


@Jacob Champion: thanks for submitting this patch and backporting it to
the 2.4.x branch.


In addition I noticed the following glitch:

Index: support/ab.c
===
--- support/ab.c(revision 1792155)
+++ support/ab.c(working copy)
@@ -2465,14 +2465,14 @@
 case 'B':
 myhost = apr_pstrdup(cntxt, opt_arg);
 break;
+case 'm':
+method = CUSTOM_METHOD;
+method_str[CUSTOM_METHOD] = strdup(opt_arg);
+break;
 #ifdef USE_SSL
 case 'Z':
 ssl_cipher = strdup(opt_arg);
 break;
-case 'm':
-method = CUSTOM_METHOD;
-method_str[CUSTOM_METHOD] = strdup(opt_arg);
-break;
 case 'f':
 #if OPENSSL_VERSION_NUMBER < 0x1010L
 if (strncasecmp(opt_arg, "ALL", 3) == 0) {


The "-m" option is independent of SSL use and should be handled outside
of "#ifdef USE_SSL".


This patch is not submitted. Any idea why? After all, the help text of
'ab' mentions ' -m method  Method name', but for instance '-m HEAD' has
no effect al all with 'ab', only with 'abs'.


Thanks for the reminder. Fixed in r1796493 for trunk and 2.4.x backport 
proposal added.


Regards,

Rainer

Re: The drive for 2.4.26

[Jan Ehrhardt]

Rainer Jung in gmane.comp.apache.devel (Fri, 21 Apr 2017 00:29:38
+0200):
>Thanks for the analysis. So the following patch on trunk works for me 
>when using OpenSSL 1.0.1e (on Solaris 10):
>
>Index: support/ab.c
>===
>--- support/ab.c(revision 1792155)
>+++ support/ab.c(working copy)
>@@ -2576,8 +2576,6 @@
>  #else
>  #if OPENSSL_VERSION_NUMBER < 0x1010L
>  CRYPTO_malloc_init();
>-#else
>-OPENSSL_malloc_init();
>  #endif
>  #endif
>  SSL_load_error_strings();
>
>
>The same fix should apply for 2.4.x.

@Jacob Champion: thanks for submitting this patch and backporting it to
the 2.4.x branch.

>In addition I noticed the following glitch:
>
>Index: support/ab.c
>===
>--- support/ab.c(revision 1792155)
>+++ support/ab.c(working copy)
>@@ -2465,14 +2465,14 @@
>  case 'B':
>  myhost = apr_pstrdup(cntxt, opt_arg);
>  break;
>+case 'm':
>+method = CUSTOM_METHOD;
>+method_str[CUSTOM_METHOD] = strdup(opt_arg);
>+break;
>  #ifdef USE_SSL
>  case 'Z':
>  ssl_cipher = strdup(opt_arg);
>  break;
>-case 'm':
>-method = CUSTOM_METHOD;
>-method_str[CUSTOM_METHOD] = strdup(opt_arg);
>-break;
>  case 'f':
>  #if OPENSSL_VERSION_NUMBER < 0x1010L
>  if (strncasecmp(opt_arg, "ALL", 3) == 0) {
>
>
>The "-m" option is independent of SSL use and should be handled outside 
>of "#ifdef USE_SSL".

This patch is not submitted. Any idea why? After all, the help text of
'ab' mentions ' -m method  Method name', but for instance '-m HEAD' has
no effect al all with 'ab', only with 'abs'.
-- 
Jan

Re: The drive for 2.4.26

[Luca Toscano]

Hi Jim,

2017-05-25 14:23 GMT+02:00 Jim Jagielski :

> Until a proposal in in STATUS (and apologies if it is), its
> suitability for 2.4.x is a big unknown.


you are completely right, afaik the last patch tested by Stefan Priebe was
https://bz.apache.org/bugzilla/attachment.cgi?id=34641=diff (Stefan
correct me if I am wrong).

If I remember correctly it might be possible that some commits were not
necessary since they were made as a test to remove segfaults that we
discovered due to other things. I'll wait Yann's feedback but if anybody
wants to check the patch it would be really great.

Thanks!

Luca

Re: The drive for 2.4.26

[Jim Jagielski]

Until a proposal in in STATUS (and apologies if it is), its
suitability for 2.4.x is a big unknown.
> On May 24, 2017, at 12:42 PM, Luca Toscano  wrote:
> 
> 
> 
> 2017-05-22 16:35 GMT+02:00 Jim Jagielski :
> I think we are *really* close! What say we try for a T
> sometime this week?
> 
> Who wants to RM? If no one does, I will.
> 
> One last thing! :) 
> 
> I am wondering if we could think about reviewing/backporting to 2.4.x the 
> code that Yann wrote (and Stefan Priebe tested together with mod_http2 
> enhancements) to allow mpm-event to use APR_POLLSET_WAKEABLE (avoiding 
> periodical wakeups every 100ms - IIRC - even if idling). 
> 
> It seems stable enough after some testing in a real world use case scenario.
> 
> Yann, any opinion? 
> 
> Luca

Re: The drive for 2.4.26

[Luca Toscano]

2017-05-22 16:35 GMT+02:00 Jim Jagielski :

> I think we are *really* close! What say we try for a T
> sometime this week?
>
> Who wants to RM? If no one does, I will.
>

One last thing! :)

I am wondering if we could think about reviewing/backporting to 2.4.x the
code that Yann wrote (and Stefan Priebe tested together with mod_http2
enhancements) to allow mpm-event to use APR_POLLSET_WAKEABLE (avoiding
periodical wakeups every 100ms - IIRC - even if idling).

It seems stable enough after some testing in a real world use case scenario.

Yann, any opinion?

Luca

Re: The drive for 2.4.26

[Gregg Smith]

Yes it did, thanks for following up.

On 5/22/2017 9:23 AM, Jacob Champion wrote:

On 04/20/2017 01:06 PM, Gregg Smith wrote:

This is ApacheBench, Version 2.3 <$Revision: 1750960 $>
Same result with trunk, it just hangs.

Glad it's not just Windows!


Gregg, did Rainer's patch work for you on Windows? Looks like it hasn't 
been pushed into trunk yet, so I'll apply it today and will be proposing 
for backport.


--Jacob

Re: The drive for 2.4.26

[Jacob Champion]

On 04/20/2017 01:06 PM, Gregg Smith wrote:

This is ApacheBench, Version 2.3 <$Revision: 1750960 $>
Same result with trunk, it just hangs.

Glad it's not just Windows!


Gregg, did Rainer's patch work for you on Windows? Looks like it hasn't 
been pushed into trunk yet, so I'll apply it today and will be proposing 
for backport.


--Jacob

Re: The drive for 2.4.26

[Jim Jagielski]

I think we are *really* close! What say we try for a T
sometime this week?

Who wants to RM? If no one does, I will.

Re: The drive for 2.4.26

[Jan Ehrhardt]

Rainer Jung in gmane.comp.apache.devel (Fri, 21 Apr 2017 00:29:38
+0200):
>Thanks for the analysis. So the following patch on trunk works for me 
>when using OpenSSL 1.0.1e (on Solaris 10):
>
>Index: support/ab.c
>===
>--- support/ab.c(revision 1792155)
>+++ support/ab.c(working copy)
>@@ -2576,8 +2576,6 @@
>  #else
>  #if OPENSSL_VERSION_NUMBER < 0x1010L
>  CRYPTO_malloc_init();
>-#else
>-OPENSSL_malloc_init();
>  #endif
>  #endif
>  SSL_load_error_strings();
>
>
>The same fix should apply for 2.4.x.
>
>In addition I noticed the following glitch:
>
>Index: support/ab.c
>===
>--- support/ab.c(revision 1792155)
>+++ support/ab.c(working copy)
>@@ -2465,14 +2465,14 @@
>  case 'B':
>  myhost = apr_pstrdup(cntxt, opt_arg);
>  break;
>+case 'm':
>+method = CUSTOM_METHOD;
>+method_str[CUSTOM_METHOD] = strdup(opt_arg);
>+break;
>  #ifdef USE_SSL
>  case 'Z':
>  ssl_cipher = strdup(opt_arg);
>  break;
>-case 'm':
>-method = CUSTOM_METHOD;
>-method_str[CUSTOM_METHOD] = strdup(opt_arg);
>-break;
>  case 'f':
>  #if OPENSSL_VERSION_NUMBER < 0x1010L
>  if (strncasecmp(opt_arg, "ALL", 3) == 0) {
>
>
>The "-m" option is independent of SSL use and should be handled outside 
>of "#ifdef USE_SSL".
>
>Will apply some time over the weekend if noone does it before.

Thia fixes abs.exe with OpenSSL 1.1.0e on Windows (VC14 x64). ould you
backport it to the 2.4.x branch?

See https://www.apachelounge.com/viewtopic.php?p=35304#35304 as well.
-- 
Jan

Re: The drive for 2.4.26

[William A Rowe Jr]

On May 2, 2017 4:35 AM, "Steffen"  wrote:

Nothing w.r.t. OSSL 1.1.x with 1.5.x apr will work, nor would 2.5.25
>
( does w.r.t means: with respect to ? )

Again Bill, please be accurate:

mod_ssl with OSSL 1.1 and 1.5 apr works !

Just build and tested it:

[Tue May 02 11:23:54.334403 2017] [ssl:info] [pid 3948:tid 652] AH01876:
mod_ssl/2.4.26-dev compiled against Server: Apache/2.4.26-dev, Library:
OpenSSL/1.1.0e
[Tue May 02 11:23:54.334403 2017] [:notice] [pid 3948:tid 652] ModSecurity:
APR compiled version="1.5.2"; loaded version="1.5.2"
[Tue May 02 11:23:54.365670 2017] [http2:info] [pid 3948:tid 652] AH03090:
mod_http2 (v1.10.3, feats=, nghttp2 1.21.1), initializing...
[Tue May 02 11:23:54.365670 2017] [mpm_winnt:notice] [pid 3948:tid 652]
AH00354: Child: Starting 64 worker threads


Ahhh... This is without apr-util crypto?!? That aught to work.

The only worry might be a 1.5 generation apr-util compiled against OpenSSL
1.1, which I would be dubious of.

If apr is not speaking to OSSL then mod_ssl would have no problems.

Re: The drive for 2.4.26

[Stefan Eissing]

> Am 02.05.2017 um 11:37 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>:
> 
>> 
>> Am 02.05.2017 um 11:35 schrieb Steffen <i...@apachelounge.com>:
>> 
>>> Nothing w.r.t. OSSL 1.1.x with 1.5.x apr will work, nor would 2.5.25
>> ( does w.r.t means: with respect to ? )
>> 
>> Again Bill, please be accurate:
>> 
>> mod_ssl with OSSL 1.1 and 1.5 apr works !
>> 
>> Just build and tested it:
>> 
>> [Tue May 02 11:23:54.334403 2017] [ssl:info] [pid 3948:tid 652] AH01876: 
>> mod_ssl/2.4.26-dev compiled against Server: Apache/2.4.26-dev, Library: 
>> OpenSSL/1.1.0e
>> [Tue May 02 11:23:54.334403 2017] [:notice] [pid 3948:tid 652] ModSecurity: 
>> APR compiled version="1.5.2"; loaded version="1.5.2"
>> [Tue May 02 11:23:54.365670 2017] [http2:info] [pid 3948:tid 652] AH03090: 
>> mod_http2 (v1.10.3, feats=, nghttp2 1.21.1), initializing...
>> [Tue May 02 11:23:54.365670 2017] [mpm_winnt:notice] [pid 3948:tid 652] 
>> AH00354: Child: Starting 64 worker threads
>> 
> I see the same under MacOS:
> 
> [Tue May 02 11:36:53.463093 2017] [http2:info] [pid 1799:tid 140736644027328] 
> AH03090: mod_http2 (v1.10.3, feats=CHPRIO+SHA256+INVHD+DWINS, nghttp2 
> 1.21.1), initializing...
> [Tue May 02 11:36:53.463160 2017] [proxy_http2:info] [pid 1799:tid 
> 140736644027328] AH03349: mod_proxy_http2 (v1.10.3, nghttp2 1.21.1), 
> initializing...
> [Tue May 02 11:36:53.464313 2017] [mpm_event:notice] [pid 1799:tid 
> 140736644027328] AH00489: Apache/2.4.26-dev (Unix) OpenSSL/1.1.0e configured 
> -- resuming normal operations
> [Tue May 02 11:36:53.464353 2017] [core:notice] [pid 1799:tid 
> 140736644027328] AH00094: Command line: '/opt/apache-2.4.x/bin/httpd -d 
> /Users/sei/projects/httpd/test/mod_h2/2.4.x/gen/apache'

FTR:
11:38:21 delight:~/projects/httpd/test/mod_h2/2.4.x> /opt/apache-2.4.x/bin/apxs 
-q | fgrep APR
APR_VERSION=1.5.3
APR_BINDIR=/opt/apache-2.4.x/bin
APR_INCLUDEDIR=/opt/apache-2.4.x/include
APR_CONFIG=/opt/apache-2.4.x/bin/apr-1-config

> So, where do we differ?
> 
>> -Original Message- From: William A Rowe Jr
>> Sent: Tuesday, May 2, 2017 8:24 AM
>> To: httpd
>> Subject: Re: The drive for 2.4.26
>> 
>> On Tue, May 2, 2017 at 1:17 AM, Steffen <i...@apachelounge.com> wrote:
>>> Resume: With next 2.4 we have two not working with 1.1.  namely abs.exe 
>>> with apr 1.6 and mod_session_crypto with 1.5.
>> 
>> Nothing w.r.t. OSSL 1.1.x with 1.5.x apr will work, nor would 2.5.25, so 
>> tell us
>> something we don't know.
>> 
>> But... What is the progress on fixing the BIO / constructors with OpenSSL 
>> 1.1.0
>> and abs in the current 2.5-branch? Any updates folks? The httpd pipeline 
>> never
>> used them (Steffen, you mention you add some of the logic into your build, 
>> but
>> that must be for the BIO-oriented 3p modules.) But a broken ab is a 
>> showstopper. 

Re: The drive for 2.4.26

[Stefan Eissing]

> Am 02.05.2017 um 11:35 schrieb Steffen <i...@apachelounge.com>:
> 
>> Nothing w.r.t. OSSL 1.1.x with 1.5.x apr will work, nor would 2.5.25
> ( does w.r.t means: with respect to ? )
> 
> Again Bill, please be accurate:
> 
> mod_ssl with OSSL 1.1 and 1.5 apr works !
> 
> Just build and tested it:
> 
> [Tue May 02 11:23:54.334403 2017] [ssl:info] [pid 3948:tid 652] AH01876: 
> mod_ssl/2.4.26-dev compiled against Server: Apache/2.4.26-dev, Library: 
> OpenSSL/1.1.0e
> [Tue May 02 11:23:54.334403 2017] [:notice] [pid 3948:tid 652] ModSecurity: 
> APR compiled version="1.5.2"; loaded version="1.5.2"
> [Tue May 02 11:23:54.365670 2017] [http2:info] [pid 3948:tid 652] AH03090: 
> mod_http2 (v1.10.3, feats=, nghttp2 1.21.1), initializing...
> [Tue May 02 11:23:54.365670 2017] [mpm_winnt:notice] [pid 3948:tid 652] 
> AH00354: Child: Starting 64 worker threads
> 
I see the same under MacOS:

[Tue May 02 11:36:53.463093 2017] [http2:info] [pid 1799:tid 140736644027328] 
AH03090: mod_http2 (v1.10.3, feats=CHPRIO+SHA256+INVHD+DWINS, nghttp2 1.21.1), 
initializing...
[Tue May 02 11:36:53.463160 2017] [proxy_http2:info] [pid 1799:tid 
140736644027328] AH03349: mod_proxy_http2 (v1.10.3, nghttp2 1.21.1), 
initializing...
[Tue May 02 11:36:53.464313 2017] [mpm_event:notice] [pid 1799:tid 
140736644027328] AH00489: Apache/2.4.26-dev (Unix) OpenSSL/1.1.0e configured -- 
resuming normal operations
[Tue May 02 11:36:53.464353 2017] [core:notice] [pid 1799:tid 140736644027328] 
AH00094: Command line: '/opt/apache-2.4.x/bin/httpd -d 
/Users/sei/projects/httpd/test/mod_h2/2.4.x/gen/apache'

So, where do we differ?

> -Original Message----- From: William A Rowe Jr
> Sent: Tuesday, May 2, 2017 8:24 AM
> To: httpd
> Subject: Re: The drive for 2.4.26
> 
> On Tue, May 2, 2017 at 1:17 AM, Steffen <i...@apachelounge.com> wrote:
>> Resume: With next 2.4 we have two not working with 1.1.  namely abs.exe with 
>> apr 1.6 and mod_session_crypto with 1.5.
> 
> Nothing w.r.t. OSSL 1.1.x with 1.5.x apr will work, nor would 2.5.25, so tell 
> us
> something we don't know.
> 
> But... What is the progress on fixing the BIO / constructors with OpenSSL 
> 1.1.0
> and abs in the current 2.5-branch? Any updates folks? The httpd pipeline never
> used them (Steffen, you mention you add some of the logic into your build, but
> that must be for the BIO-oriented 3p modules.) But a broken ab is a 
> showstopper. 

Re: The drive for 2.4.26

[Steffen]

Nothing w.r.t. OSSL 1.1.x with 1.5.x apr will work, nor would 2.5.25

( does w.r.t means: with respect to ? )

Again Bill, please be accurate:

mod_ssl with OSSL 1.1 and 1.5 apr works !

Just build and tested it:

[Tue May 02 11:23:54.334403 2017] [ssl:info] [pid 3948:tid 652] AH01876: 
mod_ssl/2.4.26-dev compiled against Server: Apache/2.4.26-dev, Library: 
OpenSSL/1.1.0e
[Tue May 02 11:23:54.334403 2017] [:notice] [pid 3948:tid 652] ModSecurity: 
APR compiled version="1.5.2"; loaded version="1.5.2"
[Tue May 02 11:23:54.365670 2017] [http2:info] [pid 3948:tid 652] AH03090: 
mod_http2 (v1.10.3, feats=, nghttp2 1.21.1), initializing...
[Tue May 02 11:23:54.365670 2017] [mpm_winnt:notice] [pid 3948:tid 652] 
AH00354: Child: Starting 64 worker threads



-Original Message- 
From: William A Rowe Jr

Sent: Tuesday, May 2, 2017 8:24 AM
To: httpd
Subject: Re: The drive for 2.4.26

On Tue, May 2, 2017 at 1:17 AM, Steffen <i...@apachelounge.com> wrote:
Resume: With next 2.4 we have two not working with 1.1.  namely abs.exe 
with apr 1.6 and mod_session_crypto with 1.5.


Nothing w.r.t. OSSL 1.1.x with 1.5.x apr will work, nor would 2.5.25, so 
tell us

something we don't know.

But... What is the progress on fixing the BIO / constructors with OpenSSL 
1.1.0
and abs in the current 2.5-branch? Any updates folks? The httpd pipeline 
never
used them (Steffen, you mention you add some of the logic into your build, 
but
that must be for the BIO-oriented 3p modules.) But a broken ab is a 
showstopper. 

Re: The drive for 2.4.26

[William A Rowe Jr]

Very sorry Steffen, I really appreciate your effort, and enthusiasm, I read
this as a direct reply to one of my notes. Blaiming my email app threading
for the confusion, thanks for reconfirming to Gregg.

OSSL can't work against 1.5 APR nor 2.4.25 but I hope we have it all sorted
for the next releases all around.

Cheers,

Bill


On May 2, 2017 3:02 AM, "Steffen"  wrote:

Gregg was wondering in one of his latest posts if this issues are still
there after his commits , so I checked it and reported back here.

Sorry for my posts dear Bill, looks you do not like them. You suggest that
I stop reporting here. Next time I wait when RC tarballs are available. I
respect you as a seasoned dev.


> Op 2 mei 2017 om 08:24 heeft William A Rowe Jr  het
volgende geschreven:
>
>> On Tue, May 2, 2017 at 1:17 AM, Steffen  wrote:
>> Resume: With next 2.4 we have two not working with 1.1.  namely abs.exe
with apr 1.6 and mod_session_crypto with 1.5.
>
> Nothing w.r.t. OSSL 1.1.x with 1.5.x apr will work, nor would 2.5.25, so
tell us
> something we don't know.
>
> But... What is the progress on fixing the BIO / constructors with OpenSSL
1.1.0
> and abs in the current 2.5-branch? Any updates folks? The httpd pipeline
never
> used them (Steffen, you mention you add some of the logic into your
build, but
> that must be for the BIO-oriented 3p modules.) But a broken ab is a
showstopper.

Re: The drive for 2.4.26

[Stefan Eissing]

> Am 02.05.2017 um 10:02 schrieb Steffen :
> 
> Gregg was wondering in one of his latest posts if this issues are still there 
> after his commits , so I checked it and reported back here. 
> 
> Sorry for my posts dear Bill, looks you do not like them. You suggest that I 
> stop reporting here. Next time I wait when RC tarballs are available. I 
> respect you as a seasoned dev. 
> 
> 
>> Op 2 mei 2017 om 08:24 heeft William A Rowe Jr  het 
>> volgende geschreven:
>> 
>>> On Tue, May 2, 2017 at 1:17 AM, Steffen  wrote:
>>> Resume: With next 2.4 we have two not working with 1.1.  namely abs.exe 
>>> with apr 1.6 and mod_session_crypto with 1.5.
>> 
>> Nothing w.r.t. OSSL 1.1.x with 1.5.x apr will work, nor would 2.5.25, so 
>> tell us
>> something we don't know.
>> 
>> But... What is the progress on fixing the BIO / constructors with OpenSSL 
>> 1.1.0
>> and abs in the current 2.5-branch? Any updates folks? The httpd pipeline 
>> never
>> used them (Steffen, you mention you add some of the logic into your build, 
>> but
>> that must be for the BIO-oriented 3p modules.) But a broken ab is a 
>> showstopper.

Please keep on testing and reporting your finds. There is a certain tone in 
some of Bill's posting that tends to resonate with primal part of ones brain. 
Others have already fallen victim to that. Don't let it get to you.

Cheers,

Stefan

Re: The drive for 2.4.26

[Steffen]

Gregg was wondering in one of his latest posts if this issues are still there 
after his commits , so I checked it and reported back here. 

Sorry for my posts dear Bill, looks you do not like them. You suggest that I 
stop reporting here. Next time I wait when RC tarballs are available. I respect 
you as a seasoned dev. 


> Op 2 mei 2017 om 08:24 heeft William A Rowe Jr  het 
> volgende geschreven:
> 
>> On Tue, May 2, 2017 at 1:17 AM, Steffen  wrote:
>> Resume: With next 2.4 we have two not working with 1.1.  namely abs.exe with 
>> apr 1.6 and mod_session_crypto with 1.5.
> 
> Nothing w.r.t. OSSL 1.1.x with 1.5.x apr will work, nor would 2.5.25, so tell 
> us
> something we don't know.
> 
> But... What is the progress on fixing the BIO / constructors with OpenSSL 
> 1.1.0
> and abs in the current 2.5-branch? Any updates folks? The httpd pipeline never
> used them (Steffen, you mention you add some of the logic into your build, but
> that must be for the BIO-oriented 3p modules.) But a broken ab is a 
> showstopper.

Re: The drive for 2.4.26

[William A Rowe Jr]

On Tue, May 2, 2017 at 1:17 AM, Steffen  wrote:
> Resume: With next 2.4 we have two not working with 1.1.  namely abs.exe with 
> apr 1.6 and mod_session_crypto with 1.5.

Nothing w.r.t. OSSL 1.1.x with 1.5.x apr will work, nor would 2.5.25, so tell us
something we don't know.

But... What is the progress on fixing the BIO / constructors with OpenSSL 1.1.0
and abs in the current 2.5-branch? Any updates folks? The httpd pipeline never
used them (Steffen, you mention you add some of the logic into your build, but
that must be for the BIO-oriented 3p modules.) But a broken ab is a showstopper.

Re: The drive for 2.4.26

[Steffen]

Resume: With next 2.4 we have two not working with 1.1.  namely abs.exe with 
apr 1.6 and mod_session_crypto with 1.5.

> Op 2 mei 2017 om 07:37 heeft William A Rowe Jr  het 
> volgende geschreven:
> 
>> On Mon, May 1, 2017 at 6:37 AM, Steffen  wrote:
>> No mod_session_crypto with apr & apr-util 1.5 and Openssl 1.1.0, error in
>> Apr:
>> 
>> ErrorC2079'cipherCtx' uses undefined struct 'evp_cipher_ctx_st'
>> apr_crypto_openssl
>> C:\VC15\Win32\httpd-2.4.26\srclib\apr-util\crypto\apr_crypto_openssl.c67
>> 
>> With apr & apr-util 1.6 all fine.
> 
> Yes, this was covered in my earlier post, 2.4-branch+apr 1.5.x+OSSL 1.0.2
> is all fine.
> 
> 2.4.next+OSSL 1.1.x will require apr 1.6, with an appropriate disclaimer in
> the announce.
> 
> What was your question, again?

Re: The drive for 2.4.26

[William A Rowe Jr]

On Mon, May 1, 2017 at 6:37 AM, Steffen  wrote:
> No mod_session_crypto with apr & apr-util 1.5 and Openssl 1.1.0, error in
> Apr:
>
> ErrorC2079'cipherCtx' uses undefined struct 'evp_cipher_ctx_st'
> apr_crypto_openssl
> C:\VC15\Win32\httpd-2.4.26\srclib\apr-util\crypto\apr_crypto_openssl.c67
>
> With apr & apr-util 1.6 all fine.

Yes, this was covered in my earlier post, 2.4-branch+apr 1.5.x+OSSL 1.0.2
is all fine.

2.4.next+OSSL 1.1.x will require apr 1.6, with an appropriate disclaimer in
the announce.

What was your question, again?

Re: The drive for 2.4.26

[Steffen]

No mod_session_crypto with apr & apr-util 1.5 and Openssl 1.1.0, error in 
Apr:


ErrorC2079'cipherCtx' uses undefined struct 'evp_cipher_ctx_st' 
apr_crypto_openssl 
C:\VC15\Win32\httpd-2.4.26\srclib\apr-util\crypto\apr_crypto_openssl.c67


With apr & apr-util 1.6 all fine.


-Original Message- 
From: Gregg Smith

Sent: Sunday, April 30, 2017 12:53 AM
To: dev@httpd.apache.org
Subject: Re: The drive for 2.4.26

Yes, and only with the legacy build and then only with the IDE. Those
files are static. If you build at the command line it should "just work."

When I built with apr 1.5 however apr_crypto_openssl would not build
with openssl 1.1.0. I cannot see how that has changed..

On 4/29/2017 1:42 AM, Stefan Eissing wrote:
Is this a Windows issue? I built with 1.1.0e on MacOS and apr 1.5 and saw 
no problems.



Am 28.04.2017 um 22:26 schrieb Steffen <i...@apachelounge.com>:

I doubt now. It was based on a note in cvtdsp.pl.

Maybe it is only a .dsp and xml change, which I can apply to 1.5.

Maybe Gregg can shed some light on this ?


Op 28 apr. 2017 om 22:16 heeft William A Rowe Jr <wr...@rowe-clan.net> 
het volgende geschreven:


Now that these are independent of one another, I think we can release 
before 1.6.x are released. We should just call out "New: OpenSSL 1.1.0 
support! (Upcoming APR 1.6.x is required for this support.)





On Apr 28, 2017 2:56 PM, "Steffen" <i...@apachelounge.com> wrote:
When with apr & apr-until 1.6 fine even more cooler.  Otherwise OpenSSL 
1.1 not supported.


For OpenSSL 1.1 we need apr & apr-util 1.6 to build (e.g 
apr_crypto_openssl for mod_session crypto)



Op 28 apr. 2017 om 14:14 heeft Jim Jagielski <j...@jagunet.com> het 
volgende geschreven:


It would be cool to have 2.4.26 released by ApacheCon, or even
by OSCON. There are, last I checked, 2 showstoppers on list for
2.4.26... Anyway we could address them and shoot for a T maybe
next Weds?

Re: The drive for 2.4.26

[Gregg Smith]

Yes, and only with the legacy build and then only with the IDE. Those 
files are static. If you build at the command line it should "just work."


When I built with apr 1.5 however apr_crypto_openssl would not build 
with openssl 1.1.0. I cannot see how that has changed..


On 4/29/2017 1:42 AM, Stefan Eissing wrote:

Is this a Windows issue? I built with 1.1.0e on MacOS and apr 1.5 and saw no 
problems.


Am 28.04.2017 um 22:26 schrieb Steffen :

I doubt now. It was based on a note in cvtdsp.pl.

Maybe it is only a .dsp and xml change, which I can apply to 1.5.

Maybe Gregg can shed some light on this ?



Op 28 apr. 2017 om 22:16 heeft William A Rowe Jr  het 
volgende geschreven:

Now that these are independent of one another, I think we can release before 1.6.x 
are released. We should just call out "New: OpenSSL 1.1.0 support! (Upcoming 
APR 1.6.x is required for this support.)




On Apr 28, 2017 2:56 PM, "Steffen"  wrote:
When with apr & apr-until 1.6 fine even more cooler.  Otherwise OpenSSL 1.1 not 
supported.

For OpenSSL 1.1 we need apr & apr-util 1.6 to build (e.g  apr_crypto_openssl 
for mod_session crypto)



Op 28 apr. 2017 om 14:14 heeft Jim Jagielski  het volgende 
geschreven:

It would be cool to have 2.4.26 released by ApacheCon, or even
by OSCON. There are, last I checked, 2 showstoppers on list for
2.4.26... Anyway we could address them and shoot for a T maybe
next Weds?

Re: The drive for 2.4.26

[William A Rowe Jr]

On Apr 29, 2017 12:16 PM, "Gregg Smith"  wrote:


Once APR 1.6 is released my plan is to make the change permanent next 2.4.x
then making the need for that conversion unneeded.

Openssl 1.0.2 is good till sometime in 2019, even 1.1.0 eol's before it
does so we're stuck w/ cvtdsp.pl modifying the dsp files one way or another.


I prefer that cvtdsp.pl do exactly the same thing moving forwards so
someone who just built 3 mos ago can repeat the exercise, and only someone
building OpenSSL 1.1.0 needs to cvtdsp.pl because the are seeking the new
support.

So no action on that needed now, but I'd like to discourage us from
inverting this all in the later patch you suggest during 2.4.x lifecycle.

Re: The drive for 2.4.26

[Gregg Smith]

APR 1.6 is needed for apr_crypto_openssl, obviously.

ABS: Not sure. When I originally tried building w/ APR 1.5 it didn't 
work, but it didn't work with OpenSSL 1.1 and APR 1.6 either. That has 
now been fixed by Rainer. Have not tried 1.5/1.1.0 w/ abs yet so I 
simply don't know. Feel free to try it. I have no time today to do it.


cvtdsp.pl assumes 1.6 is needed due to those first attempts and may be 
inaccurate. It's easy to just remove the xml.mak regex for 1.6 that's 
part of cvtdsp.pl -ossl11 (), there is a separate -apr16 option 
for just the one change in APR (xml.mak's location). Maybe I should 
remove the part concerning APR 1.6 from the -ossl11 option.


Once APR 1.6 is released my plan is to make the change permanent next 
2.4.x then making the need for that conversion unneeded.


Openssl 1.0.2 is good till sometime in 2019, even 1.1.0 eol's before it 
does so we're stuck w/ cvtdsp.pl modifying the dsp files one way or 
another.


Anyone with commit access for apr can remove the part to modify for 1.6 
that is included in cvtdsp.pl -ossl110 (sub toossl1) if 1.6 really isn't 
needed for ABS.


Have a family member in the hospital who had surgery yesterday so this 
is my first time to even check mail since Wednesday morning. I have to 
go back to the hospital shortly.




On 4/28/2017 1:26 PM, Steffen wrote:

I doubt now. It was based on a note in cvtdsp.pl.

Maybe it is only a .dsp and xml change, which I can apply to 1.5.

Maybe Gregg can shed some light on this ?



Op 28 apr. 2017 om 22:16 heeft William A Rowe Jr  het 
volgende geschreven:

Now that these are independent of one another, I think we can release before 1.6.x 
are released. We should just call out "New: OpenSSL 1.1.0 support! (Upcoming 
APR 1.6.x is required for this support.)




On Apr 28, 2017 2:56 PM, "Steffen"  wrote:
When with apr & apr-until 1.6 fine even more cooler.  Otherwise OpenSSL 1.1 not 
supported.

For OpenSSL 1.1 we need apr & apr-util 1.6 to build (e.g  apr_crypto_openssl 
for mod_session crypto)



Op 28 apr. 2017 om 14:14 heeft Jim Jagielski  het volgende 
geschreven:

It would be cool to have 2.4.26 released by ApacheCon, or even
by OSCON. There are, last I checked, 2 showstoppers on list for
2.4.26... Anyway we could address them and shoot for a T maybe
next Weds?

Re: The drive for 2.4.26

[Steffen]

Also no issue with apr_crypto_openssl and mod_session crypto ?

 Begin Message  
Group: gmane.comp.apache.devel 
MsgID:  

Is this a Windows issue? I built with 1.1.0e on MacOS and apr 1.5 and saw no 
problems.

>Am 28.04.2017 um 22:26 schrieb Steffen :
>
>I doubt now. It was based on a note in cvtdsp.pl. 
>
>Maybe it is only a .dsp and xml change, which I can apply to 1.5. 
>
>Maybe Gregg can shed some light on this ?
>
>
>>Op 28 apr. 2017 om 22:16 heeft William A Rowe Jr  het 
>>volgende geschreven:
>>
>>Now that these are independent of one another, I think we can release before 
>>1.6.x are released. We should just call out "New: OpenSSL 1.1.0 support! 
>>(Upcoming APR 1.6.x is required for this support.)
>>
>>
>>
>>>On Apr 28, 2017 2:56 PM, "Steffen"  wrote:
>>>When with apr & apr-until 1.6 fine even more cooler.  Otherwise OpenSSL 1.1 
>>>not supported.
>>>
>>>For OpenSSL 1.1 we need apr & apr-util 1.6 to build (e.g  apr_crypto_openssl 
>>>for mod_session crypto)
>>>
>>>
Op 28 apr. 2017 om 14:14 heeft Jim Jagielski  het 
volgende geschreven:

It would be cool to have 2.4.26 released by ApacheCon, or even
by OSCON. There are, last I checked, 2 showstoppers on list for
2.4.26... Anyway we could address them and shoot for a T maybe
next Weds?
>>>



- End Message - 

Re: The drive for 2.4.26

[Stefan Eissing]

Is this a Windows issue? I built with 1.1.0e on MacOS and apr 1.5 and saw no 
problems.

> Am 28.04.2017 um 22:26 schrieb Steffen :
> 
> I doubt now. It was based on a note in cvtdsp.pl. 
> 
> Maybe it is only a .dsp and xml change, which I can apply to 1.5. 
> 
> Maybe Gregg can shed some light on this ?
> 
> 
>> Op 28 apr. 2017 om 22:16 heeft William A Rowe Jr  het 
>> volgende geschreven:
>> 
>> Now that these are independent of one another, I think we can release before 
>> 1.6.x are released. We should just call out "New: OpenSSL 1.1.0 support! 
>> (Upcoming APR 1.6.x is required for this support.)
>> 
>> 
>> 
>>> On Apr 28, 2017 2:56 PM, "Steffen"  wrote:
>>> When with apr & apr-until 1.6 fine even more cooler.  Otherwise OpenSSL 1.1 
>>> not supported.
>>> 
>>> For OpenSSL 1.1 we need apr & apr-util 1.6 to build (e.g  
>>> apr_crypto_openssl for mod_session crypto)
>>> 
>>> 
>>> > Op 28 apr. 2017 om 14:14 heeft Jim Jagielski  het 
>>> > volgende geschreven:
>>> >
>>> > It would be cool to have 2.4.26 released by ApacheCon, or even
>>> > by OSCON. There are, last I checked, 2 showstoppers on list for
>>> > 2.4.26... Anyway we could address them and shoot for a T maybe
>>> > next Weds?
>>> 

Re: The drive for 2.4.26

[Steffen]

I doubt now. It was based on a note in cvtdsp.pl. 

Maybe it is only a .dsp and xml change, which I can apply to 1.5. 

Maybe Gregg can shed some light on this ?


> Op 28 apr. 2017 om 22:16 heeft William A Rowe Jr  het 
> volgende geschreven:
> 
> Now that these are independent of one another, I think we can release before 
> 1.6.x are released. We should just call out "New: OpenSSL 1.1.0 support! 
> (Upcoming APR 1.6.x is required for this support.)
> 
> 
> 
>> On Apr 28, 2017 2:56 PM, "Steffen"  wrote:
>> When with apr & apr-until 1.6 fine even more cooler.  Otherwise OpenSSL 1.1 
>> not supported.
>> 
>> For OpenSSL 1.1 we need apr & apr-util 1.6 to build (e.g  apr_crypto_openssl 
>> for mod_session crypto)
>> 
>> 
>> > Op 28 apr. 2017 om 14:14 heeft Jim Jagielski  het 
>> > volgende geschreven:
>> >
>> > It would be cool to have 2.4.26 released by ApacheCon, or even
>> > by OSCON. There are, last I checked, 2 showstoppers on list for
>> > 2.4.26... Anyway we could address them and shoot for a T maybe
>> > next Weds?
>> 

Re: The drive for 2.4.26

[William A Rowe Jr]

Now that these are independent of one another, I think we can release
before 1.6.x are released. We should just call out "New: OpenSSL 1.1.0
support! (Upcoming APR 1.6.x is required for this support.)



On Apr 28, 2017 2:56 PM, "Steffen"  wrote:

> When with apr & apr-until 1.6 fine even more cooler.  Otherwise OpenSSL
> 1.1 not supported.
>
> For OpenSSL 1.1 we need apr & apr-util 1.6 to build (e.g
> apr_crypto_openssl for mod_session crypto)
>
>
> > Op 28 apr. 2017 om 14:14 heeft Jim Jagielski  het
> volgende geschreven:
> >
> > It would be cool to have 2.4.26 released by ApacheCon, or even
> > by OSCON. There are, last I checked, 2 showstoppers on list for
> > 2.4.26... Anyway we could address them and shoot for a T maybe
> > next Weds?
>
>

Re: The drive for 2.4.26

[Steffen]

When with apr & apr-until 1.6 fine even more cooler.  Otherwise OpenSSL 1.1 not 
supported. 

For OpenSSL 1.1 we need apr & apr-util 1.6 to build (e.g  apr_crypto_openssl 
for mod_session crypto)


> Op 28 apr. 2017 om 14:14 heeft Jim Jagielski  het volgende 
> geschreven:
> 
> It would be cool to have 2.4.26 released by ApacheCon, or even
> by OSCON. There are, last I checked, 2 showstoppers on list for
> 2.4.26... Anyway we could address them and shoot for a T maybe
> next Weds?

Re: The drive for 2.4.26

[Jim Jagielski]

It would be cool to have 2.4.26 released by ApacheCon, or even
by OSCON. There are, last I checked, 2 showstoppers on list for
2.4.26... Anyway we could address them and shoot for a T maybe
next Weds?

Re: The drive for 2.4.26

[Rainer Jung]

Am 20.04.2017 um 21:23 schrieb Jacob Champion:

On 04/20/2017 07:31 AM, Gregg Smith wrote:

ABS doesn't work with openssl 1.1.0, on windows anyway. It builds
without warning yet doesn't work.

abs https://www.domain.com
just sits there forever and never completes or shows anything.

I cannot imagine this being a windows only problem.


I haven't tested Windows yet, but in Ubuntu, ab built with OpenSSL 1.1.0
hangs whether you're using HTTP or HTTPS.

We call OPENSSL_malloc_init(), which in 1.1.0 is documented to be
unnecessary except "in certain shared-library situations." (I haven't
found documented examples of these "situations" yet.) This is a macro
that just sets a bunch of malloc callbacks to their defaults.

Unfortunately on my machine, the "default" functions are actually
translated into PLT stubs for the linker -- it's a macro call, so it
uses the executable's addresses for the functions rather than the
library's. So CRYPTO_malloc calls the PLT stub which calls CRYPTO_malloc
which calls the PLT stub which recurses into madness. Configuring
OpenSSL with --debug turns the hang into a stack overflow like we'd expect.

On the one hand, it's arguably an API bug in OpenSSL, but I get the
feeling that we're not supposed to call most of these initialization
functions anymore as of 1.1.0.


Thanks for the analysis. So the following patch on trunk works for me 
when using OpenSSL 1.0.1e (on Solaris 10):


Index: support/ab.c
===
--- support/ab.c(revision 1792155)
+++ support/ab.c(working copy)
@@ -2576,8 +2576,6 @@
 #else
 #if OPENSSL_VERSION_NUMBER < 0x1010L
 CRYPTO_malloc_init();
-#else
-OPENSSL_malloc_init();
 #endif
 #endif
 SSL_load_error_strings();


The same fix should apply for 2.4.x.

In addition I noticed the following glitch:

Index: support/ab.c
===
--- support/ab.c(revision 1792155)
+++ support/ab.c(working copy)
@@ -2465,14 +2465,14 @@
 case 'B':
 myhost = apr_pstrdup(cntxt, opt_arg);
 break;
+case 'm':
+method = CUSTOM_METHOD;
+method_str[CUSTOM_METHOD] = strdup(opt_arg);
+break;
 #ifdef USE_SSL
 case 'Z':
 ssl_cipher = strdup(opt_arg);
 break;
-case 'm':
-method = CUSTOM_METHOD;
-method_str[CUSTOM_METHOD] = strdup(opt_arg);
-break;
 case 'f':
 #if OPENSSL_VERSION_NUMBER < 0x1010L
 if (strncasecmp(opt_arg, "ALL", 3) == 0) {


The "-m" option is independent of SSL use and should be handled outside 
of "#ifdef USE_SSL".


Will apply some time over the weekend if noone does it before.

Regards,

Rainer

Re: The drive for 2.4.26

[Gregg Smith]

This is ApacheBench, Version 2.3 <$Revision: 1750960 $>
Same result with trunk, it just hangs.

Glad it's not just Windows!

On 4/20/2017 9:48 AM, Rainer Jung wrote:

Am 20.04.2017 um 16:31 schrieb Gregg Smith:

ABS doesn't work with openssl 1.1.0, on windows anyway. It builds
without warning yet doesn't work.

abs https://www.domain.com
just sits there forever and never completes or shows anything.

I cannot imagine this being a windows only problem.


Any chance you can try the trunk version:

https://svn.apache.org/repos/asf/httpd/httpd/trunk/support/ab.c

The chances are good, that you can simply replace the ab.c source file
and recompile. No need to compile a complete httpd trunk. If the trunk
version works, we could focus on the delta which is not huge but
noticeable.

Thanks!

Rainer


On 4/20/2017 3:24 AM, Jim Jagielski wrote:

We are very, very close to being in a releasable state... looks
like just 1 show-stopper. If we also want to wait until APR 1.6
is released, we can also look at having redis/memcached parity in
socache as well, which would be good for 2.4.26...

Thoughts?

PS: it would be great to have this out by ApacheCon next month.

Re: The drive for 2.4.26

[Jacob Champion]

On 04/20/2017 07:31 AM, Gregg Smith wrote:

ABS doesn't work with openssl 1.1.0, on windows anyway. It builds
without warning yet doesn't work.

abs https://www.domain.com
just sits there forever and never completes or shows anything.

I cannot imagine this being a windows only problem.


I haven't tested Windows yet, but in Ubuntu, ab built with OpenSSL 1.1.0 
hangs whether you're using HTTP or HTTPS.


We call OPENSSL_malloc_init(), which in 1.1.0 is documented to be 
unnecessary except "in certain shared-library situations." (I haven't 
found documented examples of these "situations" yet.) This is a macro 
that just sets a bunch of malloc callbacks to their defaults.


Unfortunately on my machine, the "default" functions are actually 
translated into PLT stubs for the linker -- it's a macro call, so it 
uses the executable's addresses for the functions rather than the 
library's. So CRYPTO_malloc calls the PLT stub which calls CRYPTO_malloc 
which calls the PLT stub which recurses into madness. Configuring 
OpenSSL with --debug turns the hang into a stack overflow like we'd expect.


On the one hand, it's arguably an API bug in OpenSSL, but I get the 
feeling that we're not supposed to call most of these initialization 
functions anymore as of 1.1.0.


--Jacob

Re: The drive for 2.4.26

[Rainer Jung]

Am 20.04.2017 um 16:31 schrieb Gregg Smith:

ABS doesn't work with openssl 1.1.0, on windows anyway. It builds
without warning yet doesn't work.

abs https://www.domain.com
just sits there forever and never completes or shows anything.

I cannot imagine this being a windows only problem.


Any chance you can try the trunk version:

https://svn.apache.org/repos/asf/httpd/httpd/trunk/support/ab.c

The chances are good, that you can simply replace the ab.c source file 
and recompile. No need to compile a complete httpd trunk. If the trunk 
version works, we could focus on the delta which is not huge but noticeable.


Thanks!

Rainer


On 4/20/2017 3:24 AM, Jim Jagielski wrote:

We are very, very close to being in a releasable state... looks
like just 1 show-stopper. If we also want to wait until APR 1.6
is released, we can also look at having redis/memcached parity in
socache as well, which would be good for 2.4.26...

Thoughts?

PS: it would be great to have this out by ApacheCon next month.

Re: The drive for 2.4.26

[Gregg Smith]

ABS doesn't work with openssl 1.1.0, on windows anyway. It builds 
without warning yet doesn't work.


abs https://www.domain.com
just sits there forever and never completes or shows anything.

I cannot imagine this being a windows only problem.

On 4/20/2017 3:24 AM, Jim Jagielski wrote:

We are very, very close to being in a releasable state... looks
like just 1 show-stopper. If we also want to wait until APR 1.6
is released, we can also look at having redis/memcached parity in
socache as well, which would be good for 2.4.26...

Thoughts?

PS: it would be great to have this out by ApacheCon next month.

Re: The drive for 2.4.26

[Jim Jagielski]

We are very, very close to being in a releasable state... looks
like just 1 show-stopper. If we also want to wait until APR 1.6
is released, we can also look at having redis/memcached parity in
socache as well, which would be good for 2.4.26...

Thoughts?

PS: it would be great to have this out by ApacheCon next month.

Re: The drive for 2.4.26

[Stefan Eissing]

Nice work, looking forward to seeing this backported!

> Am 10.04.2017 um 18:24 schrieb Evgeny Kotkov :
> 
> Jim Jagielski  writes:
> 
>> Let's shoot for a 2.4.26 within the next handful of
>> weeks. There are some entries in STATUS that could
>> use some love and attention, and I'm hoping/pushing
>> for a Brotli[1] release so we can fold *that* capability
>> in as well.
>> 
>> 1. https://github.com/google/brotli
>>   https://github.com/google/brotli/issues/483
> 
> I noticed that the current mod_brotli backport proposal lacks a couple of
> changes that allow building against the official repository.  I think that
> the core change (excluding the docs) should be:
> 
>https://svn.apache.org/r1761714
>https://svn.apache.org/r1761824
>https://svn.apache.org/r1762512
>https://svn.apache.org/r1762515
>https://svn.apache.org/r1771789
>https://svn.apache.org/r1771791
>https://svn.apache.org/r1771827
>https://svn.apache.org/r1779077
>https://svn.apache.org/r1779111
>https://svn.apache.org/r1779700
>https://svn.apache.org/r1790852
>https://svn.apache.org/r1790853
>https://svn.apache.org/r1790860
> 
> For the convenience, here is a shortlog for these changes:
> 
>r1761714: Add initial implementation.
> 
>r1761824: Unbreak building other filter modules without libbrotlienc.
> 
>r1762512: Allow compression ratio logging with new BrotliFilterNote
>directive.
> 
>r1762515: Handle new 'no-brotli' internal environment variable that
>disables Brotli compression for a particular request.
> 
>r1771789: Rewrite the autoconf script in a, hopefully, less convoluted way.
>This lays the groundwork to simplify the switch to the official Brotli
>library.
> 
>r1771791: Explicitly cast 'const uint8_t *' to 'const char *' when using
>the data received from Brotli to create a bucket.
> 
>r1771827: Update makefiles to use the library layout of the official
>Brotli repository.
> 
>r1779077: Unused variable error could mistakenly note that brotli isn't
>available.
> 
>r1779111: Update makefile to cope with the pkg-config layout change
>in https://github.com/google/brotli/commit/fe9f9a9
> 
>r1779700: Save a few bytes and a few cycles.
> 
>r1790852: Update makefile to allow using Brotli library >= 0.6.0.
> 
>r1790853: Fix a minor typo in the description of BrotliAlterETag
>that has been referring to httpd 2.2.x.
> 
>r1790860: Comment on the default choice (0) for BROTLI_PARAM_LGBLOCK.
> 
> 
> Regards,
> Evgeny Kotkov

Re: The drive for 2.4.26

[Evgeny Kotkov]

Jim Jagielski  writes:

> Let's shoot for a 2.4.26 within the next handful of
> weeks. There are some entries in STATUS that could
> use some love and attention, and I'm hoping/pushing
> for a Brotli[1] release so we can fold *that* capability
> in as well.
>
> 1. https://github.com/google/brotli
>https://github.com/google/brotli/issues/483

I noticed that the current mod_brotli backport proposal lacks a couple of
changes that allow building against the official repository.  I think that
the core change (excluding the docs) should be:

https://svn.apache.org/r1761714
https://svn.apache.org/r1761824
https://svn.apache.org/r1762512
https://svn.apache.org/r1762515
https://svn.apache.org/r1771789
https://svn.apache.org/r1771791
https://svn.apache.org/r1771827
https://svn.apache.org/r1779077
https://svn.apache.org/r1779111
https://svn.apache.org/r1779700
https://svn.apache.org/r1790852
https://svn.apache.org/r1790853
https://svn.apache.org/r1790860

For the convenience, here is a shortlog for these changes:

r1761714: Add initial implementation.

r1761824: Unbreak building other filter modules without libbrotlienc.

r1762512: Allow compression ratio logging with new BrotliFilterNote
directive.

r1762515: Handle new 'no-brotli' internal environment variable that
disables Brotli compression for a particular request.

r1771789: Rewrite the autoconf script in a, hopefully, less convoluted way.
This lays the groundwork to simplify the switch to the official Brotli
library.

r1771791: Explicitly cast 'const uint8_t *' to 'const char *' when using
the data received from Brotli to create a bucket.

r1771827: Update makefiles to use the library layout of the official
Brotli repository.

r1779077: Unused variable error could mistakenly note that brotli isn't
available.

r1779111: Update makefile to cope with the pkg-config layout change
in https://github.com/google/brotli/commit/fe9f9a9

r1779700: Save a few bytes and a few cycles.

r1790852: Update makefile to allow using Brotli library >= 0.6.0.

r1790853: Fix a minor typo in the description of BrotliAlterETag
that has been referring to httpd 2.2.x.

r1790860: Comment on the default choice (0) for BROTLI_PARAM_LGBLOCK.


Regards,
Evgeny Kotkov

Re: The drive for 2.4.26

[William A Rowe Jr]

On Wed, Mar 29, 2017 at 2:37 PM, Jim Jagielski  wrote:
> Let's shoot for a 2.4.26 within the next handful of
> weeks.

++1 - my only question is whether we can get an apr[-util] release in the
next week or two ahead of our release, to encourage users to update their
entire stack?

> There are some entries in STATUS that could
> use some love and attention, and I'm hoping/pushing
> for a Brotli[1] release so we can fold *that* capability
> in as well.
>
> 1. https://github.com/google/brotli
>https://github.com/google/brotli/issues/483

+1. The docs are still lacking, I'm hoping to add some caveats about never
using the module dynamically unless fronted with a content cache. It seems
like we might need an entire docs page dedicated to content encoding to
keep folks from doing things like enabling this module (except for significantly
large generated content), but dynamically routing requests to corresponding
.br or .gz content files as the client advertises. The current
copy-paste silliness
for static content misses interop between brotli and gzip, disabling compression
to half of all clients. Given this limited issue and ~1 week - this
seems fixable.

With luck we can fix remoteip PROXY support to do what the spec says, as
well.

The drive for 2.4.26

[Jim Jagielski]

Let's shoot for a 2.4.26 within the next handful of
weeks. There are some entries in STATUS that could
use some love and attention, and I'm hoping/pushing
for a Brotli[1] release so we can fold *that* capability
in as well.

1. https://github.com/google/brotli
   https://github.com/google/brotli/issues/483