You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Evgeny Kotkov <ev...@visualsvn.com> on 2017/04/10 16:24:47 UTC
Re: The drive for 2.4.26
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 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