You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2017/03/29 19:37:55 UTC
The drive for 2.4.26
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
Re: The drive for 2.4.26
Posted by Jan Ehrhardt <ph...@ehrhardt.nl>.
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
Posted by Jan Ehrhardt <ph...@ehrhardt.nl>.
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
Posted by Rainer Jung <ra...@kippdata.de>.
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
Posted by Jan Ehrhardt <ph...@ehrhardt.nl>.
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
Posted by Rainer Jung <ra...@kippdata.de>.
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
Posted by Rainer Jung <ra...@kippdata.de>.
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 < 0x10100000L
>> 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 < 0x10100000L
>> 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
Posted by Jan Ehrhardt <ph...@ehrhardt.nl>.
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 < 0x10100000L
> 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 < 0x10100000L
> 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
Posted by Jan Ehrhardt <ph...@ehrhardt.nl>.
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 < 0x10100000L
> 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 < 0x10100000L
> 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
Posted by Rainer Jung <ra...@kippdata.de>.
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 < 0x10100000L
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 < 0x10100000L
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
Posted by Jacob Champion <ch...@gmail.com>.
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
Posted by Gregg Smith <gl...@gknw.net>.
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
Posted by Jacob Champion <ch...@gmail.com>.
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
Posted by Gregg Smith <gl...@gknw.net>.
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
Posted by Rainer Jung <ra...@kippdata.de>.
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
Posted by Gregg Smith <gl...@gknw.net>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Posted by Stefan Eissing <st...@greenbytes.de>.
Nice work, looking forward to seeing this backported!
> Am 10.04.2017 um 18:24 schrieb Evgeny Kotkov <ev...@visualsvn.com>:
>
> Jim Jagielski <ji...@jagunet.com> 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
Posted by Evgeny Kotkov <ev...@visualsvn.com>.
Jim Jagielski <ji...@jagunet.com> 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
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Apr 29, 2017 12:16 PM, "Gregg Smith" <gl...@gknw.net> 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
Posted by Gregg Smith <gl...@gknw.net>.
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 (&toossl1), 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 <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" <in...@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 <ji...@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&R maybe
>>>> next Weds?
>>>
>
Re: The drive for 2.4.26
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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" <in...@apachelounge.com> 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 <wr...@rowe-clan.net> het
volgende geschreven:
>
>> On Tue, May 2, 2017 at 1:17 AM, Steffen <in...@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
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 02.05.2017 um 10:02 schrieb Steffen <in...@apachelounge.com>:
>
> 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 <wr...@rowe-clan.net> het volgende geschreven:
>>
>>> On Tue, May 2, 2017 at 1:17 AM, Steffen <in...@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.
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
Posted by Steffen <in...@apachelounge.com>.
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 <wr...@rowe-clan.net> het volgende geschreven:
>
>> On Tue, May 2, 2017 at 1:17 AM, Steffen <in...@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
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 02.05.2017 um 11:37 schrieb Stefan Eissing <st...@greenbytes.de>:
>
>>
>> Am 02.05.2017 um 11:35 schrieb Steffen <in...@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 <in...@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
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 02.05.2017 um 11:35 schrieb Steffen <in...@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 <in...@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
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On May 2, 2017 4:35 AM, "Steffen" <in...@apachelounge.com> 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
Posted by Steffen <in...@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
-----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 <in...@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
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, May 2, 2017 at 1:17 AM, Steffen <in...@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
Posted by Steffen <in...@apachelounge.com>.
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 <wr...@rowe-clan.net> het volgende geschreven:
>
>> On Mon, May 1, 2017 at 6:37 AM, Steffen <in...@apachelounge.com> wrote:
>> No mod_session_crypto with apr & apr-util 1.5 and Openssl 1.1.0, error in
>> Apr:
>>
>> Error C2079 '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.c 67
>>
>> 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
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, May 1, 2017 at 6:37 AM, Steffen <in...@apachelounge.com> wrote:
> No mod_session_crypto with apr & apr-util 1.5 and Openssl 1.1.0, error in
> Apr:
>
> Error C2079 '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.c 67
>
> 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
Posted by Steffen <in...@apachelounge.com>.
No mod_session_crypto with apr & apr-util 1.5 and Openssl 1.1.0, error in
Apr:
Error C2079 '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.c 67
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 <in...@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" <in...@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 <ji...@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&R maybe
>>>>> next Weds?
>>>>
>
Re: The drive for 2.4.26
Posted by Gregg Smith <gl...@gknw.net>.
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 <in...@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" <in...@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 <ji...@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&R maybe
>>>>> next Weds?
>>>>
>
Re: The drive for 2.4.26
Posted by Stefan Eissing <st...@greenbytes.de>.
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 <in...@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" <in...@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 <ji...@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&R maybe
>>> > next Weds?
>>>
Re: The drive for 2.4.26
Posted by Steffen <in...@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" <in...@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 <ji...@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&R maybe
>> > next Weds?
>>
Re: The drive for 2.4.26
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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" <in...@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 <ji...@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&R maybe
> > next Weds?
>
>
Re: The drive for 2.4.26
Posted by Steffen <in...@apachelounge.com>.
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 <ji...@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&R maybe
> next Weds?
Re: The drive for 2.4.26
Posted by Jim Jagielski <ji...@jaguNET.com>.
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&R maybe
next Weds?
Re: The drive for 2.4.26
Posted by Yann Ylavic <yl...@gmail.com>.
Hi,
On Sun, May 28, 2017 at 8:38 PM, Stefan Priebe - Profihost AG
<s....@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 <jim@jagunet.com
>> <ma...@jagunet.com>>:
>>
>> 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&action=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
Posted by Stefan Priebe - Profihost AG <s....@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 <jim@jagunet.com
> <ma...@jagunet.com>>:
>
> 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&action=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
Posted by Luca Toscano <to...@gmail.com>.
Hi Jim,
2017-05-25 14:23 GMT+02:00 Jim Jagielski <ji...@jagunet.com>:
> 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&action=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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <to...@gmail.com> wrote:
>
>
>
> 2017-05-22 16:35 GMT+02:00 Jim Jagielski <ji...@jagunet.com>:
> I think we are *really* close! What say we try for a T&R
> 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
Posted by Luca Toscano <to...@gmail.com>.
2017-05-22 16:35 GMT+02:00 Jim Jagielski <ji...@jagunet.com>:
> I think we are *really* close! What say we try for a T&R
> 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
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, May 30, 2017 at 3:01 PM, Eric Covener <co...@gmail.com> wrote:
> On Tue, May 30, 2017 at 8:57 AM, Jim Jagielski <ji...@jagunet.com> 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&R 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
Posted by Eric Covener <co...@gmail.com>.
On Tue, May 30, 2017 at 8:57 AM, Jim Jagielski <ji...@jagunet.com> 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&R of 2.4.26.
>
> Comments? Feedback?
+1, better to bank a release with what's in now.
Re: The drive for 2.4.26
Posted by Jim Jagielski <ji...@jaguNET.com>.
There was a delay in doing the T&R 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
Posted by Jim Jagielski <ji...@jaguNET.com>.
Still looking at a T&R today... I will RM unless someone else
would like to do so!
Re: The drive for 2.4.26
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jun 8, 2017 at 11:07 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> Perfect... I propose a T&R 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
Posted by Jim Jagielski <ji...@jaguNET.com>.
Perfect... I propose a T&R on Monday... comments?
> On Jun 6, 2017, at 5:23 AM, Stefan Eissing <st...@greenbytes.de> wrote:
>
> Backported. Will also release v1.10.6 on github shortly.
>
>> Am 06.06.2017 um 10:53 schrieb Stefan Eissing <st...@greenbytes.de>:
>>
>>>
>>> Am 06.06.2017 um 10:45 schrieb Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>:
>>>
>>>
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: Stefan Eissing [mailto:stefan.eissing@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
>>>> <st...@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 <co...@gmail.com>:
>>>>>>
>>>>>> On Tue, May 30, 2017 at 9:12 AM, Stefan Eissing
>>>>>> <st...@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
>>>>>> covener@gmail.com
>
Re: The drive for 2.4.26
Posted by Stefan Eissing <st...@greenbytes.de>.
Backported. Will also release v1.10.6 on github shortly.
> Am 06.06.2017 um 10:53 schrieb Stefan Eissing <st...@greenbytes.de>:
>
>>
>> Am 06.06.2017 um 10:45 schrieb Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>:
>>
>>
>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Stefan Eissing [mailto:stefan.eissing@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
>>> <st...@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 <co...@gmail.com>:
>>>>>
>>>>> On Tue, May 30, 2017 at 9:12 AM, Stefan Eissing
>>>>> <st...@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
>>>>> covener@gmail.com
Re: The drive for 2.4.26
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 06.06.2017 um 10:45 schrieb Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>:
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Stefan Eissing [mailto:stefan.eissing@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
>> <st...@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 <co...@gmail.com>:
>>>>
>>>> On Tue, May 30, 2017 at 9:12 AM, Stefan Eissing
>>>> <st...@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
>>>> covener@gmail.com
>>>
>
AW: The drive for 2.4.26
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Stefan Eissing [mailto:stefan.eissing@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
> <st...@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 <co...@gmail.com>:
> >>
> >> On Tue, May 30, 2017 at 9:12 AM, Stefan Eissing
> >> <st...@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
> >> covener@gmail.com
> >
Re: The drive for 2.4.26
Posted by Stefan Eissing <st...@greenbytes.de>.
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 <st...@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 <co...@gmail.com>:
>>
>> On Tue, May 30, 2017 at 9:12 AM, Stefan Eissing
>> <st...@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
>> covener@gmail.com
>
Re: The drive for 2.4.26
Posted by Stefan Eissing <st...@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 <co...@gmail.com>:
>
> On Tue, May 30, 2017 at 9:12 AM, Stefan Eissing
> <st...@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
> covener@gmail.com
Re: The drive for 2.4.26
Posted by Eric Covener <co...@gmail.com>.
On Tue, May 30, 2017 at 9:12 AM, Stefan Eissing
<st...@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
covener@gmail.com
Re: The drive for 2.4.26
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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 <ji...@jagunet.com> wrote:
> I think we should wait on a T&R to resolve this issue...
>
>> On May 30, 2017, at 9:12 AM, Stefan Eissing <st...@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.
Re: The drive for 2.4.26
Posted by Jim Jagielski <ji...@jaguNET.com>.
I think we should wait on a T&R to resolve this issue...
> On May 30, 2017, at 9:12 AM, Stefan Eissing <st...@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.
>
Re: The drive for 2.4.26
Posted by Stefan Eissing <st...@greenbytes.de>.
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 <ji...@jaguNET.com>:
>
> 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&R of 2.4.26.
>
> Comments? Feedback?
r1792092 (Was: Re: The drive for 2.4.26)
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Posted by Steffen <in...@apachelounge.com>.
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 <ji...@jaguNET.com> 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&R of 2.4.26.
>
> Comments? Feedback?
Re: The drive for 2.4.26
Posted by Steffen <in...@apachelounge.com>.
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 <ji...@jaguNET.com> 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&R of 2.4.26.
>
> Comments? Feedback?
Re: The drive for 2.4.26
Posted by Jim Jagielski <ji...@jaguNET.com>.
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&R of 2.4.26.
Comments? Feedback?
Re: The drive for 2.4.26
Posted by Jim Jagielski <ji...@jaguNET.com>.
I think we are *really* close! What say we try for a T&R
sometime this week?
Who wants to RM? If no one does, I will.
Re: The drive for 2.4.26
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Mar 29, 2017 at 2:37 PM, Jim Jagielski <ji...@jagunet.com> 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.