Re: svn commit: r1897858 - in /httpd/httpd/trunk: ./ changes-entries/
Small typo below ... Am 08.02.2022 um 12:04 schrieb yla...@apache.org: Author: ylavic Date: Tue Feb 8 11:04:49 2022 New Revision: 1897858 URL: http://svn.apache.org/viewvc?rev=1897858&view=rev Log: Sync CHANGES entries. [skip ci] Removed: httpd/httpd/trunk/changes-entries/CoreDumpDirectory-freebsd11.txt httpd/httpd/trunk/changes-entries/ap_regex_thread_local.txt httpd/httpd/trunk/changes-entries/bz_65769.txt httpd/httpd/trunk/changes-entries/mod_dav_memory_regresssion.txt httpd/httpd/trunk/changes-entries/mod_md_status_memory.txt httpd/httpd/trunk/changes-entries/mod_tls_link_issue_with_rust_1_56.txt httpd/httpd/trunk/changes-entries/reqtimeout_mode_init.txt Modified: httpd/httpd/trunk/CHANGES Modified: httpd/httpd/trunk/CHANGES URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1897858&r1=1897857&r2=1897858&view=diff == --- httpd/httpd/trunk/CHANGES [utf-8] (original) +++ httpd/httpd/trunk/CHANGES [utf-8] Tue Feb 8 11:04:49 2022 @@ -1,6 +1,32 @@ -*- coding: utf-8 -*- Changes with Apache 2.5.1 + *) mod_md: the status description in MDomain's JSON, exposed in the + md-status handler (if configure) did sometimes not carry the correct + message when certificates needed renew. + [Stefan Eissing] + + *) mod_tls: Fix a linkage issue with rustls when compiled + with rust 1.55, 1.56 or 1.57. This prevents the loading + of the module because of an undefined symbol: fmaf + See https://github.com/rustls/rustls-ffi/issues/133 + [Christophe Jaillet] + + *) ap_regex: Use Thread Local Storage (TLS) to recycle ap_regexec() buffers + when an efficient TLS implementation is available. [Yann Ylavic] + + *) mom_reqtimeout: Fix missing handshake= timeout enforcement. [Yann Ylavic] s/mom_/mod_/
Re: [VOTE] Release httpd-2.4.53-rc1 as httpd-2.4.53
Am 07.03.2022 um 16:55 schrieb Stefan Eissing: Hi all, Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball httpd-2.4.53-rc1 as 2.4.53: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha256: 7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3 *httpd-2.4.53-rc1.tar.gz sha512: a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961 *httpd-2.4.53-rc1.tar.gz The SVN candidate source is found at tags/2.4.53-rc1-candidate. Kind Regards, Stefan Not a vote yet, just an observation: on SLES12 (gcc 4.8.3, glibc 2.19) and RHEL7 (gcc 4.8.2, glibc 2.19) with platform compilers, configure detects it wants to set -std=gnu11. During make I get a compilation error: server/util.c:3183:1: error: unknown type name ‘_Thread_local’ The type "_Thread_local" comes from include/httpd.h: 2438 #if defined(__cplusplus) && __cplusplus >= 201103L 2439 #define AP_THREAD_LOCAL thread_local 2440 #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112 2441 #define AP_THREAD_LOCAL _Thread_local 2442 #elif defined(__GNUC__) /* works for clang too */ 2443 #define AP_THREAD_LOCAL __thread 2444 #elif defined(WIN32) && defined(_MSC_VER) 2445 #define AP_THREAD_LOCAL __declspec(thread) 2446 #endif 2447 #endif /* ndef AP_NO_THREAD_LOCAL */ It looks like the detection is broken? Best regards, Rainer
Re: [VOTE] Release httpd-2.4.53-rc1 as httpd-2.4.53
Am 08.03.2022 um 16:33 schrieb Rainer Jung: Am 07.03.2022 um 16:55 schrieb Stefan Eissing: Hi all, Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball httpd-2.4.53-rc1 as 2.4.53: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha256: 7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3 *httpd-2.4.53-rc1.tar.gz sha512: a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961 *httpd-2.4.53-rc1.tar.gz The SVN candidate source is found at tags/2.4.53-rc1-candidate. Kind Regards, Stefan Not a vote yet, just an observation: on SLES12 (gcc 4.8.3, glibc 2.19) and RHEL7 (gcc 4.8.2, glibc 2.19) with platform compilers, configure detects it wants to set -std=gnu11. During make I get a compilation error: server/util.c:3183:1: error: unknown type name ‘_Thread_local’ The type "_Thread_local" comes from include/httpd.h: 2438 #if defined(__cplusplus) && __cplusplus >= 201103L 2439 #define AP_THREAD_LOCAL thread_local 2440 #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112 2441 #define AP_THREAD_LOCAL _Thread_local 2442 #elif defined(__GNUC__) /* works for clang too */ 2443 #define AP_THREAD_LOCAL __thread 2444 #elif defined(WIN32) && defined(_MSC_VER) 2445 #define AP_THREAD_LOCAL __declspec(thread) 2446 #endif 2447 #endif /* ndef AP_NO_THREAD_LOCAL */ It looks like the detection is broken? See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066
Re: [VOTE] Release httpd-2.4.53-rc1 as httpd-2.4.53
Am 08.03.2022 um 17:06 schrieb Ruediger Pluem: On 3/8/22 4:38 PM, Rainer Jung wrote: Am 08.03.2022 um 16:33 schrieb Rainer Jung: Am 07.03.2022 um 16:55 schrieb Stefan Eissing: Hi all, Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball httpd-2.4.53-rc1 as 2.4.53: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha256: 7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3 *httpd-2.4.53-rc1.tar.gz sha512: a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961 *httpd-2.4.53-rc1.tar.gz The SVN candidate source is found at tags/2.4.53-rc1-candidate. Kind Regards, Stefan Not a vote yet, just an observation: on SLES12 (gcc 4.8.3, glibc 2.19) and RHEL7 (gcc 4.8.2, glibc 2.19) with platform compilers, configure detects it wants to set -std=gnu11. During make I get a compilation error: server/util.c:3183:1: error: unknown type name ‘_Thread_local’ The type "_Thread_local" comes from include/httpd.h: 2438 #if defined(__cplusplus) && __cplusplus >= 201103L 2439 #define AP_THREAD_LOCAL thread_local 2440 #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112 2441 #define AP_THREAD_LOCAL _Thread_local 2442 #elif defined(__GNUC__) /* works for clang too */ 2443 #define AP_THREAD_LOCAL __thread 2444 #elif defined(WIN32) && defined(_MSC_VER) 2445 #define AP_THREAD_LOCAL __declspec(thread) 2446 #endif 2447 #endif /* ndef AP_NO_THREAD_LOCAL */ It looks like the detection is broken? See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066 Thanks for the pointer. Does the below fix it? Index: include/httpd.h === --- include/httpd.h (revision 1898730) +++ include/httpd.h (working copy) @@ -2587,7 +2587,9 @@ */ #if defined(__cplusplus) && __cplusplus >= 201103L #define AP_THREAD_LOCAL thread_local -#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112 +#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112 && \ + (!defined(__GNUC__) || \ + __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 9)) #define AP_THREAD_LOCAL _Thread_local #elif defined(__GNUC__) /* works for clang too */ #define AP_THREAD_LOCAL __thread Regards Rüdiger Looks good to me from inspection. I already tested a similar but not as good patch. The next builds will pick up your one. Will report back in an hour or so, whether it works for me. Two additional things I already saw, but which are non.critical: - configure flag --with-pcre no longer accepts an external pcre 8 installation directory. It seems in that case the flag must now point to the path of the pcre-config script instead. - configure for APR in the dependency tarball still fails for me due to a bug in autoconf 2.71 used to create the configure script. That problem was already reported by me during another release vote. I replaced the changed three files in the bundled apr and apr-util with the earlier ones. Thanks and regards, Rainer
Re: [VOTE] Release httpd-2.4.53-rc1 as httpd-2.4.53
Am 08.03.2022 um 18:22 schrieb Rainer Jung: Am 08.03.2022 um 17:06 schrieb Ruediger Pluem: On 3/8/22 4:38 PM, Rainer Jung wrote: Am 08.03.2022 um 16:33 schrieb Rainer Jung: Am 07.03.2022 um 16:55 schrieb Stefan Eissing: Hi all, Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball httpd-2.4.53-rc1 as 2.4.53: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha256: 7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3 *httpd-2.4.53-rc1.tar.gz sha512: a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961 *httpd-2.4.53-rc1.tar.gz The SVN candidate source is found at tags/2.4.53-rc1-candidate. Kind Regards, Stefan Not a vote yet, just an observation: on SLES12 (gcc 4.8.3, glibc 2.19) and RHEL7 (gcc 4.8.2, glibc 2.19) with platform compilers, configure detects it wants to set -std=gnu11. During make I get a compilation error: server/util.c:3183:1: error: unknown type name ‘_Thread_local’ The type "_Thread_local" comes from include/httpd.h: 2438 #if defined(__cplusplus) && __cplusplus >= 201103L 2439 #define AP_THREAD_LOCAL thread_local 2440 #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112 2441 #define AP_THREAD_LOCAL _Thread_local 2442 #elif defined(__GNUC__) /* works for clang too */ 2443 #define AP_THREAD_LOCAL __thread 2444 #elif defined(WIN32) && defined(_MSC_VER) 2445 #define AP_THREAD_LOCAL __declspec(thread) 2446 #endif 2447 #endif /* ndef AP_NO_THREAD_LOCAL */ It looks like the detection is broken? See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066 Thanks for the pointer. Does the below fix it? Index: include/httpd.h === --- include/httpd.h (revision 1898730) +++ include/httpd.h (working copy) @@ -2587,7 +2587,9 @@ */ #if defined(__cplusplus) && __cplusplus >= 201103L #define AP_THREAD_LOCAL thread_local -#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112 +#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112 && \ + (!defined(__GNUC__) || \ + __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 9)) #define AP_THREAD_LOCAL _Thread_local #elif defined(__GNUC__) /* works for clang too */ #define AP_THREAD_LOCAL __thread Regards Rüdiger Looks good to me from inspection. I already tested a similar but not as good patch. The next builds will pick up your one. Will report back in an hour or so, whether it works for me. Two additional things I already saw, but which are non.critical: - configure flag --with-pcre no longer accepts an external pcre 8 installation directory. It seems in that case the flag must now point to the path of the pcre-config script instead. - configure for APR in the dependency tarball still fails for me due to a bug in autoconf 2.71 used to create the configure script. That problem was already reported by me during another release vote. I replaced the changed three files in the bundled apr and apr-util with the earlier ones. Thanks and regards, Rainer You gcc 4.8 workaround for _Thread_local still looks good. Solaris builds and all unit tests not yet done but compiles fine for all my Linuxes. Thanks! Rainer
Re: [VOTE] Release httpd-2.4.53-rc1 as httpd-2.4.53
Am 09.03.2022 um 08:37 schrieb Ruediger Pluem: On 3/8/22 10:09 PM, Rainer Jung wrote: You gcc 4.8 workaround for _Thread_local still looks good. Solaris builds and all unit tests not yet done but compiles fine for all my Linuxes. Thanks! Thanks for testing. I committed to trunk as r1898771 to throw it into our CI. If we need to tweak it further we can do later. BTW: Once we have a final patch the same needs to be done for APR trunk and APR 1.8.x. Interesting: I did also compile APR trunk in my httpd release preparations but didn't observe the failure. This probably was due to the fact, that our APR trunk configure does not decide to add -std=gnu11, so the test in the header file doesn't result in _Thread_local being used. Of course it still makes sense to apply the same patch (and also to other APR branches containing the thread local code). Just wondering, whether the different handling of the"std" compiler flag for httpd and apr trunk is intentional. Best regards, Rainer
Re: [VOTE] Release httpd-2.4.53-rc1 as httpd-2.4.53
Am 09.03.2022 um 13:58 schrieb Ruediger Pluem: On 3/9/22 11:34 AM, Rainer Jung wrote: Am 09.03.2022 um 08:37 schrieb Ruediger Pluem: On 3/8/22 10:09 PM, Rainer Jung wrote: You gcc 4.8 workaround for _Thread_local still looks good. Solaris builds and all unit tests not yet done but compiles fine for all my Linuxes. Thanks! Thanks for testing. I committed to trunk as r1898771 to throw it into our CI. If we need to tweak it further we can do later. BTW: Once we have a final patch the same needs to be done for APR trunk and APR 1.8.x. Interesting: I did also compile APR trunk in my httpd release preparations but didn't observe the failure. This probably was due to the fact, that our APR trunk configure does not decide to add -std=gnu11, so the test in the header file doesn't result in _Thread_local being used. Of course it still makes sense to apply the same patch (and also to other APR branches containing the thread local code). Just wondering, whether the different handling of the"std" compiler flag for httpd and apr trunk is intentional. Weird. I don't see -std=gnu11 added at all to my httpd build on RedHat 8. gcc --version gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4) autoconf --version autoconf (GNU Autoconf) 2.69 But I have tested the patch and get AP_THREAD_LOCAL set to _Thread_local as it should. Good. Concerning RHEL 8: I see the flag there neither due to: RHEl7 : checking for gcc -specs=/shared/build/autobuild/specs/specs.rhel7 option to enable C11 features... -std=gnu11 RHEL 8: checking for gcc -specs=/shared/build/autobuild/specs/specs.rhel8 option to enable C11 features... none needed The check for C11 was introduced in autoconf 2.70 as a new feature of "AC_PROG_CC", which we have in configure.in for httpd and for APR. The observed behavioral difference between httpd configure and (my) APR trunk configure is due to the fact, that I generated my APR trunk configure with autoconf 2.69, so the check does not run there. But it would, once configure would be regenerated with modern autoconf. So indeed the thread local detection fix should go in APR as well. Thanks and regards, Rainer
About our autoconf problems
First thanks to Stefan for downgrading his release system. It is a good workaround for the observed problems. Since downgrades are not a long term solution, here's the status info to avoid confusion. We observed two problems that had to do with using a recent autoconf version (2.70 an above) during releasing: - bundled APR configure broken (ongoing) This is already fixed by adjusting one of our autoconf macros in APR 1.7.x and trunk (I think not in 1.6.x). But we didn't have an APR release since a long time, so the deps tarball for httpd still contains the latest but unfixed APR version. Once we will have a new APR release und bundle that, this autoconf problem will be gone and the latest autoconf should again be fine. - thread local detection broken in httpd.h (fixed) This is not a configure time problem, but a compile time problem. But it is still related to configure, because since autoconf 2.70 our call to AC_PROG_CC also checks whether the compiler support C11. For some gcc versions, eg. 4.8.x, this leads in "-std=gnu11" being added to the compiler flags. This in combination with httpd.h in 2.4.53-rc1 lead to a compile time failure. That problem is now fixed by making httpd.h more robust, so fir that problem the downgrade is no longer needed. Thanks and regards, Rainer
Support JSON output in mod_status and mod_info
I am thinking about adding a JSON output format to mod_status and mod_info as an option controlled by a query string parameter. Since writing simple data structures from these modules is much simpler than parsing and processing a JSON structure, I would expect it to be based on simple ap_rputs() and ap_rprintf() like we already use it for auto (text) and HTML output. IMHO no need for a JSON library just for this use case. Of course, this will slightly bloat the code with "if" statements and roughly double the amount of ap_rputs() and ap_rprintf(). For mod_status this probably means introduction of a new AP_STATUS_JSON value, so that in theory other modules could in the future update their status extensions with JSON support. In the meantime it might mean, that if a modules extends mod_status output, the result when asking for JSON output is no valid JSON (mix between mod_status JSON and mod_something providing HTML or text). For our own modules, especially mod_proxy, this can of course be fixed (and I will fix this). For mod_info, we do not have such an extension problem wrt. 3rd-party modules. Any comments up-front before I try to prototype this? Thanks and regards, Rainer
Re: Support JSON output in mod_status and mod_info
Am 28.03.2022 um 15:24 schrieb Stefan Eissing: Am 28.03.2022 um 14:28 schrieb Rainer Jung : I am thinking about adding a JSON output format to mod_status and mod_info as an option controlled by a query string parameter. Since writing simple data structures from these modules is much simpler than parsing and processing a JSON structure, I would expect it to be based on simple ap_rputs() and ap_rprintf() like we already use it for auto (text) and HTML output. IMHO no need for a JSON library just for this use case. Of course, this will slightly bloat the code with "if" statements and roughly double the amount of ap_rputs() and ap_rprintf(). For mod_status this probably means introduction of a new AP_STATUS_JSON value, so that in theory other modules could in the future update their status extensions with JSON support. In the meantime it might mean, that if a modules extends mod_status output, the result when asking for JSON output is no valid JSON (mix between mod_status JSON and mod_something providing HTML or text). For our own modules, especially mod_proxy, this can of course be fixed (and I will fix this). For mod_info, we do not have such an extension problem wrt. 3rd-party modules. Any comments up-front before I try to prototype this? +1 (a big one) Suggestion: we could add an additional `status_hook` like `status_json_hook` so that existing one do not get confused? Doh, of course, haven't thought about this degree of freedom. Makes sense. Need to think how to make that new registration future feature proof, so that we don't need a new hook for every new status feature which is output incompatible. Thanks and regards, Rainer
Current status of mod_h2 test suite?
I try to make the mod_h2 test suite run for me. Some difficulties are expected due to my non-standard setup, but the first test that seems to fail in a way I am not directly blaming myself is fuzz header * on http://test.example.org:12345: super-long...--- gen/expect_431 2022-04-05 13:25:40.081886486 +0200 +++ gen/result 2022-04-05 13:25:40.138887222 +0200 @@ -1,2 +1,2 @@ ---> 0:1 GET / -> 431 0 +--> 0:1 GET / -> 431 273 0/0/1/0/0 (2/3/4/5/0xx) It seems the test expects 0 body bytes but the web server sends: 2.0//EN">\n\n431 Request Header Fields Too Large\n\nRequest Header Fields Too Large\nThe server refused this request because\nthe request header fields are too large.\n\n which doesn't look like an error. So is this test broken? Is the general expectation, that other fuzzing tests will succeed? Thanks for the test suite anyways. All tests before that first fuzzing test work. Best regards, Rainer
Re: Current status of mod_h2 test suite?
Hi Stefan, Am 05.04.2022 um 13:49 schrieb Stefan Eissing: Which test suite, the one in trunk or the one from github? Both work best against the respective source. the test suite in https://svn.apache.org/repos/asf/httpd/test/mod_h2/trunk Which one would you recommend to test http2 in a 2.4.x release (candidate)? Thanks and regards, Rainer Am 05.04.2022 um 13:47 schrieb Rainer Jung : I try to make the mod_h2 test suite run for me. Some difficulties are expected due to my non-standard setup, but the first test that seems to fail in a way I am not directly blaming myself is fuzz header * on http://test.example.org:12345: super-long...--- gen/expect_431 2022-04-05 13:25:40.081886486 +0200 +++ gen/result 2022-04-05 13:25:40.138887222 +0200 @@ -1,2 +1,2 @@ ---> 0:1 GET / -> 431 0 +--> 0:1 GET / -> 431 273 0/0/1/0/0 (2/3/4/5/0xx) It seems the test expects 0 body bytes but the web server sends: \n\n431 Request Header Fields Too Large\n\nRequest Header Fields Too Large\nThe server refused this request because\nthe request header fields are too large.\n\n which doesn't look like an error. So is this test broken? Is the general expectation, that other fuzzing tests will succeed? Thanks for the test suite anyways. All tests before that first fuzzing test work. Best regards, Rainer
Re: Current status of mod_h2 test suite?
Thaks, will switch to that one. Should have reembered it ... Am 05.04.2022 um 14:04 schrieb Stefan Eissing: Am 05.04.2022 um 14:01 schrieb Rainer Jung : Hi Stefan, Am 05.04.2022 um 13:49 schrieb Stefan Eissing: Which test suite, the one in trunk or the one from github? Both work best against the respective source. the test suite in https://svn.apache.org/repos/asf/httpd/test/mod_h2/trunk Oh, forgot about that one. Should remove it. Which one would you recommend to test http2 in a 2.4.x release (candidate)? The one in ^/httpd/httpd/branches/2.4.x/test/modules/http2 This is the one (and the corresponding in trunk) that also runs as part of our travis CI. There is a README.pytest in test with some advice to set it up and use. Kind Regards, Stefan Thanks and regards, Rainer Am 05.04.2022 um 13:47 schrieb Rainer Jung : I try to make the mod_h2 test suite run for me. Some difficulties are expected due to my non-standard setup, but the first test that seems to fail in a way I am not directly blaming myself is fuzz header * on http://test.example.org:12345: super-long...--- gen/expect_431 2022-04-05 13:25:40.081886486 +0200 +++ gen/result 2022-04-05 13:25:40.138887222 +0200 @@ -1,2 +1,2 @@ ---> 0:1 GET / -> 431 0 +--> 0:1 GET / -> 431 273 0/0/1/0/0 (2/3/4/5/0xx) It seems the test expects 0 body bytes but the web server sends: \n\n431 Request Header Fields Too Large\n\nRequest Header Fields Too Large\nThe server refused this request because\nthe request header fields are too large.\n\n which doesn't look like an error. So is this test broken? Is the general expectation, that other fuzzing tests will succeed? Thanks for the test suite anyways. All tests before that first fuzzing test work. Best regards, Rainer
Adding a2md to httpd sources?
Hi there, during my experiments with the nice pytest based test suite against 2.4.x I noticed, that many mod_md tests need "a2md". The sources for this commandline tool ar in Stefan's GitHub repos for mod_md, but not inside the httpd 2.4.x source tree. I have not really checked, what a2md exactly does, but was wondering, how much sense it would make to add it to 2.4.x as another support binary? From the man page: The a2md utility can be used to configure and update managed domains with the mod_md module for Apache HTTP Server. Managed Domains are virtual hosts which automatically obtain and renew TLS certificates from an ACME server. Is it ready for prime time? Would it interact with a custom build of httpd (layout might differ from distros)? What's the expectation? Thanks and regards, Rainer
Re: Adding a2md to httpd sources?
Thanks for all feedback. So no need to integrate. Note that the 2.4.x pytest suite still makes heavy use of it when testing mod_md. Thanks and regards, Rainer Am 08.04.2022 um 10:24 schrieb Steffen: Agree no need for it anymore. Ps. You wrote: I have not yet heard any questions or feedback from anyone about it….If I remember correctly, no one was around to make the cmake and Windows builds for it. I had given feedback and was able to build it on windows in 2017. In the beginning some crashes, but Stefan solved. Op 8 apr. 2022 om 09:14 heeft Stefan Eissing het volgende geschreven: Am 07.04.2022 um 13:04 schrieb Rainer Jung : Hi there, during my experiments with the nice pytest based test suite against 2.4.x I noticed, that many mod_md tests need "a2md". The sources for this commandline tool ar in Stefan's GitHub repos for mod_md, but not inside the httpd 2.4.x source tree. I have not really checked, what a2md exactly does, but was wondering, how much sense it would make to add it to 2.4.x as another support binary? From the man page: The a2md utility can be used to configure and update managed domains with the mod_md module for Apache HTTP Server. Managed Domains are virtual hosts which automatically obtain and renew TLS certificates from an ACME server. Is it ready for prime time? Would it interact with a custom build of httpd (layout might differ from distros)? What's the expectation? Some distros, who package from the github repro, seem to include a2md, but I have not yet heard any questions or feedback from anyone about it. We excluded it in the httpd build as, if I remember correctly, no one was around to make the cmake and Windows builds for it. Looking back, I do not see the need to a2md any longer. All can and should be configured in httpd's config files and information readout is available via the common status handlers and mod_md's own JSON status handler. Kind Regards, Stefan Thanks and regards, Rainer
pytest: test_101_ssl_reneg.py with OpenSSL 3.0.2 triggers error in TestBuffering.test_h2_712_03
Hi all, at the end of the test runs in the pytest suite, TestBuffering.test_h2_712_03 checks for warnings or errors logged in the httpd error log. None are allowed, but test test_101_ssl_reneg.py [ssl:error] [pid 15298:tid 140040420189952] SSL Library Error: error:0AC1:SSL routines::no shared cipher -- Too restrictive SSLCipherSuite or using DSA server certificate? [ssl:error] [pid 15298:tid 140040411797248] SSL Library Error: error:0AC7:SSL routines::peer did not return a certificate -- No CAs known to server for verification? [ssl:error] [pid 15299:tid 140040378226432] SSL Library Error: error:0AC7:SSL routines::peer did not return a certificate -- No CAs known to server for verification? [ssl:error] [pid 15299:tid 140040369833728] SSL Library Error: error:0AC1:SSL routines::no shared cipher -- Too restrictive SSLCipherSuite or using DSA server certificate? This is with OpenSSL 3.0.2. It does not happen with OpenSSL 1.1.1n (server and curl, but the nghttp2 commandline tools always using 3.0.2). I added time stamps, so I think the relevant tests, that produce the messages are: 24.04.2022 10:07:50.347236 test/modules/http2/test_101_ssl_reneg.py::TestSslRenegotiation::test_h2_101_03 PASSED: [Sun Apr 24 10:07:50.337861 2022] [ssl:error] [pid 9912:tid 139900498208512] SSL Library Error: error:0AC1:SSL routines::no shared cipher -- Too restrictive SSLCipherSuite or using DSA server certificate? 24.04.2022 10:07:50.459491 test/modules/http2/test_101_ssl_reneg.py::TestSslRenegotiation::test_h2_101_04 PASSED: [Sun Apr 24 10:07:50.451743 2022] [ssl:error] [pid 9912:tid 139900506601216] SSL Library Error: error:0AC7:SSL routines::peer did not return a certificate -- No CAs known to server for verification? 24.04.2022 10:07:50.580942 test/modules/http2/test_101_ssl_reneg.py::TestSslRenegotiation::test_h2_101_05 PASSED: [Sun Apr 24 10:07:50.572229 2022] [ssl:error] [pid 9911:tid 139900473030400] SSL Library Error: error:0AC7:SSL routines::peer did not return a certificate -- No CAs known to server for verification? 24.04.2022 10:07:50.862277 test/modules/http2/test_102_require.py::TestRequire::test_h2_102_01 PASSED: [Sun Apr 24 10:07:50.853262 2022] [ssl:error] [pid 9912:tid 139900389103360] SSL Library Error: error:0AC1:SSL routines::no shared cipher -- Too restrictive SSLCipherSuite or using DSA server certificate? I haven't thought about how to fix this, first wanted to make it known. Thanks and regards, Rainer
Re: pytest: test_101_ssl_reneg.py with OpenSSL 3.0.2 triggers error in TestBuffering.test_h2_712_03
Cool, thanks for the pointer. Will report back! Am 24.04.2022 um 22:29 schrieb Stefan Eissing: Hi Rainer, there is a list of patterns and APLOGNOs that are allowed to happen. In the http2 tests, those are defined in env.py, lines 88-97. If we get new ones with openssl 3.0.2, we need to add them there. Could you give this a shot? Kind Regards, Stefan Am 24.04.2022 um 22:03 schrieb Rainer Jung : Hi all, at the end of the test runs in the pytest suite, TestBuffering.test_h2_712_03 checks for warnings or errors logged in the httpd error log. None are allowed, but test test_101_ssl_reneg.py [ssl:error] [pid 15298:tid 140040420189952] SSL Library Error: error:0AC1:SSL routines::no shared cipher -- Too restrictive SSLCipherSuite or using DSA server certificate? [ssl:error] [pid 15298:tid 140040411797248] SSL Library Error: error:0AC7:SSL routines::peer did not return a certificate -- No CAs known to server for verification? [ssl:error] [pid 15299:tid 140040378226432] SSL Library Error: error:0AC7:SSL routines::peer did not return a certificate -- No CAs known to server for verification? [ssl:error] [pid 15299:tid 140040369833728] SSL Library Error: error:0AC1:SSL routines::no shared cipher -- Too restrictive SSLCipherSuite or using DSA server certificate? This is with OpenSSL 3.0.2. It does not happen with OpenSSL 1.1.1n (server and curl, but the nghttp2 commandline tools always using 3.0.2). I added time stamps, so I think the relevant tests, that produce the messages are: 24.04.2022 10:07:50.347236 test/modules/http2/test_101_ssl_reneg.py::TestSslRenegotiation::test_h2_101_03 PASSED: [Sun Apr 24 10:07:50.337861 2022] [ssl:error] [pid 9912:tid 139900498208512] SSL Library Error: error:0AC1:SSL routines::no shared cipher -- Too restrictive SSLCipherSuite or using DSA server certificate? 24.04.2022 10:07:50.459491 test/modules/http2/test_101_ssl_reneg.py::TestSslRenegotiation::test_h2_101_04 PASSED: [Sun Apr 24 10:07:50.451743 2022] [ssl:error] [pid 9912:tid 139900506601216] SSL Library Error: error:0AC7:SSL routines::peer did not return a certificate -- No CAs known to server for verification? 24.04.2022 10:07:50.580942 test/modules/http2/test_101_ssl_reneg.py::TestSslRenegotiation::test_h2_101_05 PASSED: [Sun Apr 24 10:07:50.572229 2022] [ssl:error] [pid 9911:tid 139900473030400] SSL Library Error: error:0AC7:SSL routines::peer did not return a certificate -- No CAs known to server for verification? 24.04.2022 10:07:50.862277 test/modules/http2/test_102_require.py::TestRequire::test_h2_102_01 PASSED: [Sun Apr 24 10:07:50.853262 2022] [ssl:error] [pid 9912:tid 139900389103360] SSL Library Error: error:0AC1:SSL routines::no shared cipher -- Too restrictive SSLCipherSuite or using DSA server certificate? I haven't thought about how to fix this, first wanted to make it known. Thanks and regards, Rainer
Re: mod_dumpio and per-dir loglevel
Am 10.05.2022 um 16:23 schrieb Eric Covener: I was looking at making some tests run more quietly, but mod_dumpio uses ap_log_cerror even though it always has a ap_filter_t when it's doing its real work. While this would still leave some early logging (pre-location walk) w/o the per-dir loglevel set yet, it would kick in by the time bodies are read/written. Can anyone anticipate any issue/concern here with using ap_log_rerror? Probably not what you are asking, but mod_dumpio in a (reverse) proxy context can log the front connection and the back connection. Maybe something to be aware of when switching from connection to request. Best regards, Rainer
Re: travis CI failing in 2.4.x
Not yet a full explanation but: - the build fails due to "The job exceeded the maximum log length, and has been terminated." shortly before line 30.000 - the difference to the succeeeding "Linux Ubuntu Focal, ASan" is, that the ErrorLog of the run is not part of this log output handled by Travis. - the lines you saw look pretty normal to me (depending on the modules we build). And it is not the exact same line repeating, but just the same type of line for every request executed during the tests. I guess, the build configs differ, so that travis handled the ErrorLog differently? Best regards, Rainer
Re: travis CI failing in 2.4.x
Forget the below. The real error was already detected by others and 25.000 lines higher in the console output: t/modules/heartbeat.t (Wstat: 0 Tests: 1 Failed: 1) Failed test: 1 Files=141, Tests=7232, 130 wallclock secs ( 2.85 usr 0.26 sys + 47.35 cusr 10.50 csys = 60.96 CPU) Result: FAIL Failed 1/141 test programs. 1/7232 subtests failed. ... Am 17.05.2022 um 15:24 schrieb Rainer Jung: Not yet a full explanation but: - the build fails due to "The job exceeded the maximum log length, and has been terminated." shortly before line 30.000 - the difference to the succeeeding "Linux Ubuntu Focal, ASan" is, that the ErrorLog of the run is not part of this log output handled by Travis. - the lines you saw look pretty normal to me (depending on the modules we build). And it is not the exact same line repeating, but just the same type of line for every request executed during the tests. I guess, the build configs differ, so that travis handled the ErrorLog differently? Best regards, Rainer
Re: svn commit: r1901009 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS changes-entries/md_acme_failover.txt changes-entries/mod_proxy_log_backend_port.txt modules/http2/h2_mplx.c modules/http2/h2_v
Hi Jim, it looks like the unrelated file changes-entries/mod_proxy_log_backend_port.txt was removed by accident during this commit? I don't see its contents already in CHANGES. I had not yet used the make target "update-changes" when applying the backend port patch, so the changes-entries file was left for final CHANGES consolidation in purpose. I will add it back soon. Best regards, Rainer Am 17.05.2022 um 20:17 schrieb j...@apache.org: Author: jim Date: Tue May 17 18:17:44 2022 New Revision: 1901009 URL: http://svn.apache.org/viewvc?rev=1901009&view=rev Log: Merge r from trunk: Submitted by: icing, rpluem, ylavic Reviewed by: jim Github: closes #317 Removed: httpd/httpd/branches/2.4.x/changes-entries/md_acme_failover.txt httpd/httpd/branches/2.4.x/changes-entries/mod_proxy_log_backend_port.txt ...
Re: release anyone?
Am 25.05.2022 um 14:15 schrieb Stefan Eissing: Anyone feeling release vibes in the air? it's been a good 2.5 months and some things have accumulated. Maybe the start of June would be a good target? +1 and thanks! Rainer
Re: [VOTE] Release httpd-2.4.54-rc3 as httpd-2.4.54
Am 06.06.2022 um 16:25 schrieb Stefan Eissing: Here we go again! Sorry for the repeats, but that is why we build candidates, right? Hi all, Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball httpd-2.4.54-rc3 as 2.4.54: [X] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. +1 to release and thanks a bunch for RM! The full range of unit tests is still running, but enough have completed for a vote. I actually used rc2 plus the one "#if" patch which got included in rc3 to build and test, but also did the simple release checks for rc3. ! KEYS maybe missing (see other mail) - Sigs and hashes OK - contents of tarballs identical - contents of tag and tarballs identical except for expected deltas Built on - Solaris 10 Sparc as 32 Bit Binaries - SLES 11+12+15 (64 Bits) - RHEL 6+7+8 (64 Bits) For all platforms built - with default (shared) and static modules (Solaris only shared modules) - with module set reallyall - using --enable-load-all-modules - using libraries - APR/APU - bundled deps tarball - 1.7.0/1.6.1 - 1.6.5/1.6.1 - 1.7.x(r1901250)/1.7.x(r1901250) with libxml2 - 1.7.x(r1901250)/1.7.x(r1901250) with expat - 1.6.x(r1898636)/1.6.x(r1901250) - trunk(r1901250) with libxml2 - trunk(r1901250) with expat - OpenSSL 3.0.3, 1.1.1o, 1.1.1, 1.0.2u, 1.0.2, 0.9.8zh, 0.9.8b - expat 2.4.8 - pcre 10.39, sometimes 10.40 - lua 5.4.4 (compiled with LUA_COMPAT_MODULE) - libxml2 2.9.14 - libnghttp2 1.47.0 - brotli 1.0.9 - curl 7.83.1 - jansson 2.14 - libldap 2.6.2 (2.5.7 with OpenSSL 1.1.1, 2.4.59 with OpenSSL 1.0.2*, 2.4.52 with OpenSSL 0.9.8*) - on Solaris also platform ldap library - in total 96 builds per platform, 60 on Solaris - Tool chain: - platform gcc except on Solaris (gcc 9.3.0 Solaris 10) - CFLAGS: -O2 -g -Wall -fno-strict-aliasing - on Solaris additionally -mpcu=v9, -D_XOPEN_SOURCE, -D_XOPEN_SOURCE_EXTENDED=1, -D__EXTENSIONS__ and -D_XPG6 All 636 builds succeeded. - compiler warnings: - only on Solaris (GCC 9.3.0): srclib/apr/locks/unix/proc_mutex.c:979:49: warning: 'mutex_proc_pthread_cond_methods' defined but not used [-Wunused-const-variable=] - deprecation warnings when building against OpenSSL 3.0.0, see other thread Tested for - SLES 11+12+15 - RHEL 6+7+8 - Solaris 10 Sparc - MPMs prefork, worker, event - log level trace8 - Perl client bundle build against OpenSSL 3.0.0, , 1.1.1g plus patches, 1.1.0l, 1.0.2u and 0.9.8zh Every OpenSSL version in the client tested with every OpenSSL version in the server. 15 unit test runs (3 MPMS x 5 OpenSSL clients) per server build. About 2.400 unit test runs are done, most for shared module builds. Some local adjustments to tests were used: - t/modules/buffer.t: removing huge buffer tests -my $bigsize = 10; +my $bigsize = 5; The following test failures were seen: a t/modules/buffer.t line 37 Test 4 (411 times), test 8 (217 times) and 12 (18 times) Not a regression Only on RHEL 6, SLES 11 and Solaris 10. b Various tests in t/modules/cgi.t, mostly lines 195 and 223, sometimes line 167 and 252 Not a regression Only on Solaris and once on RHEL 6 110 failed test runs (out of 120 on Solaris) Test checks log contents. Could be false positive due to logs written to NFS. c t/modules/sed.t line 37 test 3 91 times Solaris 10, 12 times RHEL 9, 6 times SLES 11 At least two cases I checked were "(12)Cannot allocate memory" (Linux) resp. "(12)Not enough space:" (Solaris). d A couple of tests fail for OpenSSL 0.9.8 based server when tested with a OpenSSL 3.0.0 based client: - t/modules/proxy_websockets_ssl.t - t/protocol/echo.t - t/security/CVE-2005-2700.t - t/security/CVE-2009-3555.t - t/ssl/basicauth.t - t/ssl/env.t - t/ssl/extlookup.t - t/ssl/fakeauth.t - t/ssl/headers.t - t/ssl/ocsp.t - t/ssl/pr12355.t - t/ssl/pr43738.t - t/ssl/proxy.t - t/ssl/require.t - t/ssl/varlookup.t - t/ssl/verify.t That might be expected due to the behavior of the 3.0 default security level (not investigated) Regards, Rainer > The computed digests of the tarball up for vote are: > sha256: c687b99c446c0ef345e7d86c21a8e15fc074b7d5152c4fe22b0463e2be346ffb *httpd-2.4.54-rc3.tar.gz > sha512: e9599df48a73b07b3a11dd44db2c22a671e8a41cdd5021bb434bbcde39d6fc498d165d9b0c4ed2b66a6321d9760b031c1c1c84c23661dbf44c42c52f637ec4dd *httpd-2.4.54-rc3.tar.gz > > The SVN candidate source is found at tags/2.4.54-rc3-candidate. > > Kind Regards, > Stefan
Re: svn commit: r1901514 - in /httpd/test/framework/trunk: README t/conf/extra.conf.in t/modules/sed.t
I wonder, what the following test is expected to test? I can't really
make it work reliably here. Sometimes I get an ENOMEM on the server,
sometimes it takes a long time and much CPU, sometimes the client gets a
596 AnyEvent::HTTP error and sometimes it runs ok.
Am 01.06.2022 um 15:03 schrieb cove...@apache.org:
Modified: httpd/test/framework/trunk/t/modules/sed.t
URL:
http://svn.apache.org/viewvc/httpd/test/framework/trunk/t/modules/sed.t?rev=1901514&r1=1901513&r2=1901514&view=diff
==
--- httpd/test/framework/trunk/t/modules/sed.t (original)
+++ httpd/test/framework/trunk/t/modules/sed.t Wed Jun 1 13:03:08 2022
@@ -5,29 +5,44 @@ use Apache::Test;
use Apache::TestRequest;
use Apache::TestUtil;
+# Hack to allow streaming of data in/out of mod_echo
+use LWP::Protocol::AnyEvent::http;
+
my @ts = (
# see t/conf/extra.conf.in
- { url => "/apache/sed/out-foo/foobar.html", content => 'barbar', msg => "sed output
filter", code => 200 },
- { url => "/apache/sed-echo/echo.html", content => 'barbar', msg => "sed input filter", code
=> 200, body=>"foobar" }
+ { url => "/apache/sed/out-foo/foobar.html", content => 'barbar', msg => "sed output
filter", code => '200' },
+ # error after status sent
+ { url => "/apache/sed-echo/out-foo-grow/foobar.html", content => "", msg => "sed output filter too
large", code => '200', body=>"foo" x (8192*1024), resplen=>0},
I found no other body size, that made it reliable, so therefore I am
wondering, what it would test in an ideal world.
Thanks and regards,
Rainer
Re: svn commit: r1902117 - /httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c
Am 21.06.2022 um 07:38 schrieb Ruediger Pluem: On 6/20/22 10:54 PM, rj...@apache.org wrote: Author: rjung Date: Mon Jun 20 20:54:14 2022 New Revision: 1902117 URL: http://svn.apache.org/viewvc?rev=1902117&view=rev Log: *) mod_heartmonitor: Allow "HeartbeatMaxServers 0" to use file based storage instead of slotmem. Needed after setting HeartbeatMaxServers default to the documented value 10 in 2.4.54. [Jérôme Billira Modified: httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c Modified: httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c?rev=1902117&r1=1902116&r2=1902117&view=diff == --- httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c (original) +++ httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c Mon Jun 20 20:54:14 2022 @@ -892,8 +892,9 @@ static const char *cmd_hm_maxworkers(cmd } maxworkers = atoi(data); -if (maxworkers <= 10) -return "HeartbeatMaxServers: Should be bigger than 10"; +if (maxworkers != 0 && maxworkers <= 10) Shouldn't this be < 10, such that you can set the default value via HeartbeatMaxServers. It seems strange that this can't be done. Furthermore <= 10 does not match the error message below. Oups, thank you! Hopefully fixed in r1902130 +return "HeartbeatMaxServers: Should be 0 for file storage, " + "or greater or equal than 10 for slotmem"; Shouldn't this be documented in the documentation as well that '0' has a special meaning and that 1-9 are not allowed? Done in r1902132 + r1902133 I hope I understood the correct conditions for using flat-file storage. Best regards, Rainer
pytest for 2.4.x: crashes in mod_md during child shutdown
Hi there, I ran the pytest suite on SLES 12+15 and RHEL 7+8 for 2.4.54 plus OpenSSL 1.1.1p. Ran it for event, worker and prefork and with OpenSSL 1.1.1 and 3.0 in the client. I observe sporadic segmentation faults on all of those platforms and for all MPMs and all OpenSSL versions in the client. The crashes are not especially frequent and I only have backtraces on one platform (RHEL 8). There the pattern seems to be consistently: - only two threads shown, also for event and worker - one thread is in various stacks underneath clean_child_exit() - the other thread is somewhere below md_reg_renew() run_renew() acme_renew() ... - it looks like things have already been deinitialized by the thread in clean_child_exit() when mod_md gets a renew job from mod_watchdog. Before I investigate further: is there already an expectation, that mod_watchdog should not dispatch a job after shutdown has started and vice versa shutdown should wait for a running mod_watchdog job at least some time? Or that mod_md should not execute on such a job after shutdown has started? It is probably a niche experience, but I got 20 segfaults in roughly 48 pytest suite runs. Test for httpd using OpenSSL 3.0.4 on the server side will run later today. Best regards, Rainer
mod_proxy_http2 setting Transfer-Encoding chunked for a GET request
Hi all, today I stumbled into an unexpected request denial by a rule in the mod_security Core Rule Set 3. It denies requests without body, that have Transfer-Encoding chunked set. When I send a normal GET request, without body, no Transfer-Encoding and no Content-Length, to httpd and proxy it via mod_proxy_http2 to the same server, the proxied request gets "Transfer-Encoding: chunked" added by mod_proxy_http2 and is then denied by mod_security on the receiving side. No such addition when using mod_proxy_http. It seems to me, that "Transfer-Encoding: chunked" is not allowed for http/2 (due to its always streaming behavior), and at least it is unexpected for a GET or HEAD request. Any chance we can get rid of it when proxying a request, that has no body and doesn't bring the header by its own? Should I open a PR in our bugzilla, or on the mod_h2 Github repos? Thanks and best regards, Rainer
Re: mod_proxy_http2 setting Transfer-Encoding chunked for a GET request
Hi Stefan, the PR is: https://bz.apache.org/bugzilla/show_bug.cgi?id=66282 Let me know, in case you can not reproduce it, or I should test something! Best regards, Rainer
Escaping double quotation marks in the error log
Hi there, I looked at our escaping functions for logs due to the need of doing JSON logging. In principle one can output JSON by using appropriate log format definitions in the httpd config. Most special characters in JSON are already properly escaped in our output. But there is one important difference between the escaping of access log items and of error log items. The escaping function for the access log also escapes double quotation marks as \", the one for the error log does not (ap_escape_errorlog_item). It contains the comment "no need for this in error log". This is true all the way since the time the escaping was introduced at all. I wonder, whether there is a real necessity for not escaping double quotation marks in the error log? Note, that I am not talking about markup that appears in the definition of the ErrorLogFormat itself. This is "just" about double quotation marks showing up in the error message itself (or logged headers, env vars or notes). Unfortunately the use of ap_escape_errorlog_item() is buried deep down in the code levels and accessing virtual host config seems not possible, not even in the callers of ap_escape_errorlog_item(). If there's no other nice idea, I wonder whether: - it would be OK, to escape double quotation marks as \" in the error log for trunk - add a global config item to do this as well for 2.4.x (default off) What do you think? Or did you find a better solution for error log json logging? Best regards, Rainer
Re: [VOTE] Release httpd-2.4.55-rc1 as httpd-2.4.55
Not a showstopper, but: srclib/apr/configure was again generated with autoconf 2.70+ (2.71). This triggers a bug which is fixed in APR 1.7.x head, but the fix has not been released as there was not APR release vor almost 4 years now. Since the bundled APR/APU are not actually part of the release, for me this is not a show stopper. I just wanted to note the defect in case others are wondering, why the bundled APR can not be build using configure. Technical details: configure: error: could not determine the string function for int64_t It comes from defining some things once in conftest.c and again in the included confdefs.h. Some pointers: https://github.com/apache/apr/pull/25 https://github.com/apache/apr/commit/a15958a37a06f71c42c690278f9c958b93b7ee20 https://github.com/apache/apr/commit/e0197912a5438b3836ce2e76371f01e289d82931 https://www.mail-archive.com/bug-autoconf@gnu.org/msg04695.html https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97998 Best regards, Rainer Am 10.01.23 um 14:40 schrieb Eric Covener: Hi all, Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball httpd-2.4.55-rc1 as 2.4.55: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha256: 5276ea8bc6fff31eed5c82132ae51a0b2ee05f9e6b61a00fa877f6cadab3b638 *httpd-2.4.55-rc1.tar.gz sha512: ca0d03b5e74078977378fe711ca3ed8cf63c109b7dbe73f2c43f7f30f7e522bbe46f93189a183b7675394d57fffb0c2526facd8d40508be984a7a8f64d18f8d6 *httpd-2.4.55-rc1.tar.gz The SVN candidate source is found at tags/2.4.55-rc1-candidate.
Current pytest failures
Hi there, I currently get three consistent pytest failures: A) FAILED modules/http2/test_202_trailer.py::TestTrailers::test_h2_202_03b Response code is 500 and trace 8 server log shows: - we see the right request [Wed Mar 08 22:03:35.699234 2023] [aptest:info] [pid 4606:tid 140645737559808] [remote 127.0.0.1:50490] test[test_h2_202_03b]: POST //echohd.py?name=X HTTP/2.0 [Wed Mar 08 22:03:35.699247 2023] [http:trace4] [pid 4606:tid 140645737559808] http_request.c(436): [remote 127.0.0.1:50490] Headers received from client: [Wed Mar 08 22:03:35.699254 2023] [http:trace4] [pid 4606:tid 140645737559808] http_request.c(440): [remote 127.0.0.1:50490] Accept: */* [Wed Mar 08 22:03:35.699259 2023] [http:trace4] [pid 4606:tid 140645737559808] http_request.c(440): [remote 127.0.0.1:50490] Accept-Encoding: gzip, deflate [Wed Mar 08 22:03:35.699264 2023] [http:trace4] [pid 4606:tid 140645737559808] http_request.c(440): [remote 127.0.0.1:50490] User-Agent: nghttp2/1.52.0 [Wed Mar 08 22:03:35.699268 2023] [http:trace4] [pid 4606:tid 140645737559808] http_request.c(440): [remote 127.0.0.1:50490] Content-Length: 119 [Wed Mar 08 22:03:35.699273 2023] [http:trace4] [pid 4606:tid 140645737559808] http_request.c(440): [remote 127.0.0.1:50490] Host: 127.0.0.1:5001 [Wed Mar 08 22:03:35.699277 2023] [http:trace4] [pid 4606:tid 140645737559808] http_request.c(440): [remote 127.0.0.1:50490] Ap-Test-Name: test_h2_202_03b [Wed Mar 08 22:03:35.699282 2023] [http:trace4] [pid 4606:tid 140645737559808] http_request.c(440): [remote 127.0.0.1:50490] X: 3b [Wed Mar 08 22:03:35.699425 2023] [authz_core:debug] [pid 4606:tid 140645737559808] mod_authz_core.c(818): [remote 127.0.0.1:50490] AH01626: authorization result of Require all granted: granted [Wed Mar 08 22:03:35.699440 2023] [authz_core:debug] [pid 4606:tid 140645737559808] mod_authz_core.c(818): [remote 127.0.0.1:50490] AH01626: authorization result of : granted [Wed Mar 08 22:03:35.699446 2023] [core:trace3] [pid 4606:tid 140645737559808] request.c(362): [remote 127.0.0.1:50490] request authorized without authentication by access_checker_ex hook: /echohd.py We get the right response from the python CGI script: [Wed Mar 08 22:03:35.784148 2023] [cgid:trace4] [pid 4606:tid 140645737559808] util_script.c(576): [remote 127.0.0.1:50490] Headers from script 'echohd.py': [Wed Mar 08 22:03:35.784206 2023] [cgid:trace4] [pid 4606:tid 140645737559808] util_script.c(577): [remote 127.0.0.1:50490] Status: 200 [Wed Mar 08 22:03:35.784219 2023] [cgid:trace1] [pid 4606:tid 140645737559808] util_script.c(658): [remote 127.0.0.1:50490] Status line from script 'echohd.py': 200 [Wed Mar 08 22:03:35.784234 2023] [cgid:trace4] [pid 4606:tid 140645737559808] util_script.c(577): [remote 127.0.0.1:50490] Content-Type: text/plain [Wed Mar 08 22:03:35.784255 2023] [filter:trace4] [pid 4606:tid 140645737559808] mod_filter.c(169): [remote 127.0.0.1:50490] Content-Type 'text/plain' ... [Wed Mar 08 22:03:35.784268 2023] [filter:trace4] [pid 4606:tid 140645737559808] mod_filter.c(181): [remote 127.0.0.1:50490] ... did not match 'text/html' [Wed Mar 08 22:03:35.784278 2023] [filter:trace4] [pid 4606:tid 140645737559808] mod_filter.c(175): [remote 127.0.0.1:50490] ... matched 'text/plain' deflate compression wants to kick in (no idea whether that's part of the problem) [Wed Mar 08 22:03:35.784288 2023] [filter:trace2] [pid 4606:tid 140645737559808] mod_filter.c(188): [remote 127.0.0.1:50490] Content-Type condition for 'deflate' matched and now a connection reset! [Wed Mar 08 22:03:35.788364 2023] [cgid:trace1] [pid 4606:tid 140645737559808] mod_cgid.c(1686): (104)Connection reset by peer: [remote 127.0.0.1:50490] Failed to flush CGI output to client and another request for that URL comes in: [Wed Mar 08 22:03:35.788486 2023] [ssl:debug] [pid 4606:tid 140645737559808] ssl_engine_kernel.c(422): [remote 127.0.0.1:50490] AH02034: Subsequent (No.2) HTTPS request received for child 0 (server cgi.tests.httpd.apache.org:443) [Wed Mar 08 22:03:35.788500 2023] [aptest:info] [pid 4606:tid 140645737559808] [remote 127.0.0.1:50490] test[test_h2_202_03b]: POST //echohd.py?name=X HTTP/2.0 And now we send the 500 code, probably due to the connection reset [Wed Mar 08 22:03:35.788676 2023] [http2:debug] [pid 4606:tid 140645720774400] h2_stream.c(1537): [client 127.0.0.1:50490] AH03073: h2_stream(4606-0-13,HALF_CLOSED_REMOTE): submit response 500 The access log also shows two of these requests: 127.0.0.1 - - [08/Mar/2023:22:03:35 +0100] "POST //echohd.py?name=X HTTP/2.0" 500 678 "-" "nghttp2/1.52.0" 1 127.0.0.1 - - [08/Mar/2023:22:03:35 +0100] "POST //echohd.py?name=X HTTP/2.0" 200 0 "-" "nghttp2/1.52.0" 1 And in the trace 8 error log except for the "Subsequent (No.2) HTTPS request received" I don't see where this would get a code 200 as indicated in the access log. Client side log: execute: nghttp --header=host: cgi.tests.httpd.apache.org:5
Re: Current pytest failures
Thanks for the tip. I already did the "run only one test case" and I fixed the LogLevel in test.conf to include trace8. So I guess there will not be any additional CGI logging available. But good to know the "-vvv". Thanks and regards, Rainer Am 09.03.23 um 09:33 schrieb Stefan Eissing via dev: One tip, if you call "pytest -vvv -k test_h2_202_03b", it will run just that test and raise LogLevel for several "interesting" modules. The error log in test/gen/apache/logs/error_log will then show just that one test case. It's a convenient way to get more information without meddling with the test case configs. The list of modules for which the log level is raised on "-vvv" is found in test/modules/http2/env.py:73 self.add_httpd_log_modules(["http2", "proxy_http2", "h2test", "proxy", "proxy_http"]) we can add "cgi" or others if those are of interest.
Re: Current pytest failures
I will see how to extract the test case out of pytest to be able to run it standalone and vary the protocol. But the connection reset plus second request might also be nghttp specific. I will also try running nghttp from remote and sniff to double check the connection reset plus second request. Thanks and regards, Rainer Am 09.03.23 um 09:19 schrieb Ruediger Pluem: On 3/8/23 10:44 PM, Rainer Jung wrote: Hi there, I currently get three consistent pytest failures: Do A) and B) work if you do the requests via HTTP/1.1? Regards Rüdiger
Re: Current pytest failures
OK, I can test in a standalone situation now. The problem goes away, once I use curl, even with h2. The problem also goes away, once I disable deflate compression for the response. But curl and nghttp behave different: nghttp hangs after receiving the response body (no deflate), curl normally terminates. nghttp does not hang if I call some normal production site. Will investigate further. Thanks and regards, Rainer
Re: Current pytest failures
Puzzle partially solved: once I add "--header 'content-type: application/x-www-form-urlencoded'" to the nghttp call, the problem seems fixed - with and without deflate. No more hang, no more status 500, no double requests. I still don't know, which side is influenced, nghttp or http, so I am still not sure, whether the odd behavior without the header is a bug. Am 09.03.23 um 11:03 schrieb Rainer Jung: OK, I can test in a standalone situation now. The problem goes away, once I use curl, even with h2. The problem also goes away, once I disable deflate compression for the response. But curl and nghttp behave different: nghttp hangs after receiving the response body (no deflate), curl normally terminates. nghttp does not hang if I call some normal production site. Will investigate further. Thanks and regards, Rainer
Re: Current pytest failures
Am 09.03.23 um 11:29 schrieb Stefan Eissing via dev: Am 09.03.2023 um 11:22 schrieb Rainer Jung : Puzzle partially solved: once I add "--header 'content-type: application/x-www-form-urlencoded'" to the nghttp call, the problem seems fixed - with and without deflate. No more hang, no more status 500, no double requests. I still don't know, which side is influenced, nghttp or http, so I am still not sure, whether the odd behavior without the header is a bug. Hmm, never seen that. Is this a current nghttp? Normally, calling "nghttp --data=file" will do all that. I think, since it stabilizes the test, please add the forced content-type header to the test suite. It should do no harm (famous last words), Will do. It happens with nghttp 1.34.0 and recent 1.52.0. I took the header from my curl, which automatically adds it, but I think the right header is Content-Type: multipart/form-data; boundary=DSAJKcd9876 That one is explicitly added in pyhttpd/nghttp.py in function upload_file, but not in post_name. Skimming through the code for nghttp, it seems it dows add content-length (if not forbidden by a commandline flag), but I didn't find an explicit mentioning of content-type. Best regards, Rainer
Re: [VOTE] Switch read/write repository from Subversion to Git
Am 04.05.23 um 10:34 schrieb Ruediger Pluem: This is a formal vote on whether we should move our read/write repository from Subversion to Git. This means that our latest read/write repository will be no longer available via svn.apache.org. It will be available via Git at https://gitbox.apache.org/repos/asf/httpd-site.git and https://github.com/apache/httpd.git. Github also offers the possibility to use a Subversion client: https://docs.github.com/en/get-started/working-with-subversion-on-github/support-for-subversion-clients [X]: Move the read/write repository from Subversion to Git and leverage the features of Github (for now Actions and PR). [ ]: Move the read/write repository from Subversion to Git, but I don't want to work with Github and I will only work with what gitbox.apache.org offers. [ ]: Leave everything as is. Thanks and regards, Rainer
Re: svn commit: r1909606 - /httpd/httpd/trunk/modules/generators/mod_status.c
Oups and thanks!
Am 04.05.23 um 12:30 schrieb yla...@apache.org:
Author: ylavic
Date: Thu May 4 10:30:25 2023
New Revision: 1909606
URL: http://svn.apache.org/viewvc?rev=1909606&view=rev
Log:
Follow up to r1909429: Fix scope/block syntax.
Modified:
httpd/httpd/trunk/modules/generators/mod_status.c
Modified: httpd/httpd/trunk/modules/generators/mod_status.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/generators/mod_status.c?rev=1909606&r1=1909605&r2=1909606&view=diff
==
--- httpd/httpd/trunk/modules/generators/mod_status.c (original)
+++ httpd/httpd/trunk/modules/generators/mod_status.c Thu May 4 10:30:25 2023
@@ -348,9 +348,9 @@ static int status_handler(request_rec *r
else if (res != SERVER_DEAD &&
res != SERVER_STARTING &&
res != SERVER_IDLE_KILL) {
-if (res == SERVER_GRACEFUL)
+if (res == SERVER_GRACEFUL) {
graceful++;
-if (is_async) {
+if (is_async)
thread_graceful_buffer[i]++;
} else {
busy++;
mod_ssl SSL_OP_IGNORE_UNEXPECTED_EOF: "unexpected eof while reading"
Hi there, OpenSSL 3 flags some abortive shutdowns as an error different to what 1.1.1 did. This results in info log output in httpd: [Tue Aug 29 12:33:06.787210 2023] [ssl:info] [pid 1994673:tid 1994737] SSL Library Error: error:0A000126:SSL routines::unexpected eof while reading [Tue Aug 29 12:33:06.787374 2023] [ssl:info] [pid 1994673:tid 1994737] [client 1.2.3.4:54790] AH01998: Connection closed to child 215 with abortive shutdown (server myserver:443) Some background is given in https://github.com/openssl/openssl/issues/18866 They introduced a new context option "SSL_OP_IGNORE_UNEXPECTED_EOF" to suppress this. Some other software now sets it with SSL_CTX_set_options(): - nginx https://github.com/nginx/nginx/commit/5155845ce4453a07d60e2ce43946c9181bc311fa - PHP https://github.com/php/php-src/pull/8558/commits/55be0f489e390d28892a07c32d45a404c62fc9f2 I suggest to adopt it, ie. set it if the option is available. WDYT? Best regards, Rainer
Re: mod_ssl SSL_OP_IGNORE_UNEXPECTED_EOF: "unexpected eof while reading"
Am 30.08.23 um 13:50 schrieb Stefan Eissing via dev: Am 30.08.2023 um 13:21 schrieb Rainer Jung : Hi there, OpenSSL 3 flags some abortive shutdowns as an error different to what 1.1.1 did. This results in info log output in httpd: [Tue Aug 29 12:33:06.787210 2023] [ssl:info] [pid 1994673:tid 1994737] SSL Library Error: error:0A000126:SSL routines::unexpected eof while reading [Tue Aug 29 12:33:06.787374 2023] [ssl:info] [pid 1994673:tid 1994737] [client 1.2.3.4:54790] AH01998: Connection closed to child 215 with abortive shutdown (server myserver:443) Some background is given in https://github.com/openssl/openssl/issues/18866 They introduced a new context option "SSL_OP_IGNORE_UNEXPECTED_EOF" to suppress this. Some other software now sets it with SSL_CTX_set_options(): - nginx https://github.com/nginx/nginx/commit/5155845ce4453a07d60e2ce43946c9181bc311fa - PHP https://github.com/php/php-src/pull/8558/commits/55be0f489e390d28892a07c32d45a404c62fc9f2 I suggest to adopt it, ie. set it if the option is available. WDYT? +1 to setting this for our users sake. I withhold my opinion about this stupid OpenSSL change...oops. Thanks for your feedback. I committed it to trunk in r1912015 and can revert if someone thinks its premature. Will propose for backport probably tomorrow. Best regards, Rainer
Re: balancers bybusyness, bytraffic and byrequest thread/process safe issues
Hi JFC, I have not checked ur current code, but the topic reminds me of our history in mod_jk land. There we switched the counters to atomics were available. The other problematic part could be how to handle process local counters versus global counters. Busyness was especially problematic for mod_jk as well, because we never deremented below zero if we lost increments, but if we lost decrements the counters stayed elevated. I think there we now have no longer such problems. Best regards, Rainer Am 30.08.23 um 17:19 schrieb jean-frederic clere: Hi, All the balancers have thread/process safe issues, but with bybusyness the effect is worse, basically a worker may stay with a busy count greater than zero even no request is being processed. busy is displayed in the balancer_handler() so users/customers will notice the value doesn't return to zero... If you run a load test the value of busy will increase by time and in all the workers When using bybusyness, having pics in the load and later no much load makes the lowest busy workers used and the ones with a wrong higher value not being used. In a test with 3 workers, I end with busy: worker1: 3 worker2: 0 worker3: 2 Doing the load test several time the buys values are increasing in all workers. I am wondering is we could end with something like: worker1: 1000 worker2: 0 worker3: 1000 in this case bybusyness will send all the load to worker2 until we reach 1000 simultaneous request on worker2... Obvious that looks bad. How to fix that? 1 - reset the busy using a watchdog and elected (or transferred+read) unchanged for some time (using one of timeout we have on workers). 2 - warn in the docs that bybusyness is not the best choice for loadbalancing. 3 - create another balancer that just choose random a worker.
Re: balancers bybusyness, bytraffic and byrequest thread/process safe issues
Hi there, mod_jk for example uses such aging, but only for the non busyness case. busyness is meant to show the number of currently in-flight requests, so aging isn't a good fit there. Old load numbers are never part of busyness. But busyness is the mode that is most sensitive to the numer skew effects that JFC observed. Therefore that attempt to have more precise counting there. It makes sense for byrequests and bytraffic though. But in mod_jk we use a different byrequests algorithm. Not the original count and decrement system that Mladen introduced but instead a count and age system. The aging for byrequests and bytraffic could be hooked on mod_watchdog which is nice, because we would not need to run it as part of normal request handling. Another thing that comes to my mind is (graceful) restart handlingan bybusyness. It might make sense to clear the numbers in case of such an event. Best regards, Rainer Am 31.08.23 um 18:23 schrieb Jim Jagielski: IIRC, the goal of having an "aging" function was to handle this exact kind of thing, where values could be normalized over a long period of time so that old entries that may skew results are not weighted as heavily as new ones. On Aug 30, 2023, at 11:19 AM, jean-frederic clere wrote: Hi, All the balancers have thread/process safe issues, but with bybusyness the effect is worse, basically a worker may stay with a busy count greater than zero even no request is being processed. busy is displayed in the balancer_handler() so users/customers will notice the value doesn't return to zero... If you run a load test the value of busy will increase by time and in all the workers When using bybusyness, having pics in the load and later no much load makes the lowest busy workers used and the ones with a wrong higher value not being used. In a test with 3 workers, I end with busy: worker1: 3 worker2: 0 worker3: 2 Doing the load test several time the buys values are increasing in all workers. I am wondering is we could end with something like: worker1: 1000 worker2: 0 worker3: 1000 in this case bybusyness will send all the load to worker2 until we reach 1000 simultaneous request on worker2... Obvious that looks bad. How to fix that? 1 - reset the busy using a watchdog and elected (or transferred+read) unchanged for some time (using one of timeout we have on workers). 2 - warn in the docs that bybusyness is not the best choice for loadbalancing. 3 - create another balancer that just choose random a worker. -- Cheers Jean-Frederic ´
Re: mod_ssl SSL_OP_IGNORE_UNEXPECTED_EOF: "unexpected eof while reading"
Am 07.09.23 um 14:58 schrieb Joe Orton: On Wed, Aug 30, 2023 at 01:21:11PM +0200, Rainer Jung wrote: Hi there, OpenSSL 3 flags some abortive shutdowns as an error different to what 1.1.1 did. This results in info log output in httpd: [Tue Aug 29 12:33:06.787210 2023] [ssl:info] [pid 1994673:tid 1994737] SSL Library Error: error:0A000126:SSL routines::unexpected eof while reading [Tue Aug 29 12:33:06.787374 2023] [ssl:info] [pid 1994673:tid 1994737] [client 1.2.3.4:54790] AH01998: Connection closed to child 215 with abortive shutdown (server myserver:443) Some background is given in https://github.com/openssl/openssl/issues/18866 They introduced a new context option "SSL_OP_IGNORE_UNEXPECTED_EOF" to suppress this. Some other software now sets it with SSL_CTX_set_options(): Interesting! Just wondering, is there a reason why we'd only want to enable this for server-side operation (mctx->pkp == NULL) not also for client-side/proxy operation? Seems like it might be better to enable it unconditionally. Regards, Joe Hi Joe, I just wanted to be a bit cautious. I had observed it on the server side and have no real knowledge about the client side. But I am OK, to enable this "compatibility" flag in both cases. I'll wait abit for more feedback and then adjust trunk and the backport proposal. Thanks for the feedback, Rainer
pytest: 3 minutes gap or long single test runtime
Hi all, when running the current pytest, I see a gap between two specific test outputs of more than three minutes: ... 13.09.2023 21:47:46.220943 modules/http2/test_712_buffering.py::TestBuffering::test_h2_712_03 PASSED [ 39%] 13.09.2023 21:50:55.456457 modules/md/test_001_store.py::TestStore::test_md_001_001 PASSED [ 39%] ... I assume the lines are written at the end of the respective test, so either modules/md/test_001_store.py::TestStore::test_md_001_001 takes so long, or the teardown after the test before it or startup befor thos test. Before I try to investigate more: is this happening only here, or does someone else also see this? Thanks and regards, Rainer
Re: pytest: 3 minutes gap or long single test runtime
Am 14.09.23 um 07:44 schrieb Stefan Eissing via dev: Am 13.09.2023 um 22:14 schrieb Rainer Jung : Hi all, when running the current pytest, I see a gap between two specific test outputs of more than three minutes: ... 13.09.2023 21:47:46.220943 modules/http2/test_712_buffering.py::TestBuffering::test_h2_712_03 PASSED [ 39%] 13.09.2023 21:50:55.456457 modules/md/test_001_store.py::TestStore::test_md_001_001 PASSED [ 39%] ... I assume the lines are written at the end of the respective test, so either modules/md/test_001_store.py::TestStore::test_md_001_001 takes so long, or the teardown after the test before it or startup befor thos test. Before I try to investigate more: is this happening only here, or does someone else also see this? I do not see any noticeable delay in starting the mod_md tests on my machine. The gap you see indicate to a startup problem, maybe until pebble starts responding? Thank you very much for checking. I will investigate.
Re: svn commit: r1913010 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS
Thanks for merging. I am fine with this one not making in into the final 2.4.58 release (but of course also if it goes in in case we need a seconds rc). Am 16.10.23 um 13:45 schrieb rpl...@apache.org: Author: rpluem Date: Mon Oct 16 11:45:19 2023 New Revision: 1913010 URL: http://svn.apache.org/viewvc?rev=1913010&view=rev Log: Merge r1912015 from trunk: mod_ssl: Silence info log message "SSL Library Error: error:0A000126: SSL routines::unexpected eof while reading" when using OpenSSL 3 by setting SSL_OP_IGNORE_UNEXPECTED_EOF if available. [Rainer Jung] Reviewed by: rjung, gbechis, rpluem Modified: httpd/httpd/branches/2.4.x/ (props changed) httpd/httpd/branches/2.4.x/CHANGES httpd/httpd/branches/2.4.x/STATUS Propchange: httpd/httpd/branches/2.4.x/ -- Merged /httpd/httpd/trunk:r1912015 Modified: httpd/httpd/branches/2.4.x/CHANGES URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1913010&r1=1913009&r2=1913010&view=diff == --- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original) +++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Mon Oct 16 11:45:19 2023 @@ -1,6 +1,11 @@ -*- coding: utf-8 -*- Changes with Apache 2.4.58 + *) mod_ssl: Silence info log message "SSL Library Error: error:0A000126: + SSL routines::unexpected eof while reading" when using + OpenSSL 3 by setting SSL_OP_IGNORE_UNEXPECTED_EOF if + available. [Rainer Jung] + *) mod_http2: improved early cleanup of streams. [Stefan Eissing] Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1913010&r1=1913009&r2=1913010&view=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Mon Oct 16 11:45:19 2023 @@ -152,15 +152,6 @@ RELEASE SHOWSTOPPERS: PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] - *) mod_ssl: Silence info log message "SSL Library Error: error:0A000126: - SSL routines::unexpected eof while reading" when using - OpenSSL 3 by setting SSL_OP_IGNORE_UNEXPECTED_EOF if - available. [Rainer Jung] - Trunk version of patch: -https://svn.apache.org/r1912015 - Backport version for 2.4.x of patch: -svn merge -c 1912015 ^/httpd/httpd/trunk . - +1: rjung, gbechis, rpluem PATCHES PROPOSED TO BACKPORT FROM TRUNK: [ New proposals should be added at the end of the list ]
Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58
Am 16.10.23 um 17:08 schrieb Stefan Eissing via dev: Hi all, after fixing my merge mistake in rc2 (sorry!), we go again: Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball httpd-2.4.58-rc3 as 2.4.58: [X] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha256: 503a7da4a4a27fd496037998b17078dc9fe004db32c657c96cce8356b8aa2eb6 *httpd-2.4.58-rc3.tar.gz sha512: 5c11faf0572035ef67b27775d975999411c689cb774553175299a9e99b63d3d7138b0c7f15048ec28038494d8513689f916202c2289d557947d8b190d46ca9f3 *httpd-2.4.58-rc3.tar.gz The SVN candidate source is found at tags/2.4.58-rc3-candidate. Cheers, Stefan I know I am late, but for the sake of completeness my test results: +1 to release and thanks a bunch for RM! The full range of unit tests is still running, but enough have completed for a vote. - Sigs and hashes OK - contents of tarballs identical - contents of tag and tarballs identical except for expected deltas Built on - SLES 11+12+15 (64 Bits) - RHEL 6+7+8+9 (64 Bits) For all platforms built - with default (shared) and static modules - with module set reallyall - using --enable-load-all-modules - using libraries - APR/APU - bundled deps tarball - 1.7.4/1.6.3 - 1.6.5/1.6.3 - 1.7.x(r1911757)/1.7.x(r1911757) with libxml2 - 1.7.x(r1911757)/1.7.x(r1911757) with expat - 1.6.x(r1908753)/1.6.x(r1911757) - trunk(r1911757) with libxml2 - trunk(r1911757) with expat - OpenSSL 3.1.3, 3.0.11, 1.1.1w, and for all except RHEL 9 also 1.1.1, 1.0.2u, 1.0.2 - expat 2.5.0 - pcre 10.42 - lua 5.4.6 (compiled with LUA_COMPAT_MODULE) - libxml2 2.11.5 - libnghttp2 1.57.0 - brotli 1.1.0 - curl 8.4.0 - jansson 2.14 - libldap 2.6.6 (2.5.7 with OpenSSL 1.1.1, 2.4.59 with OpenSSL 1.0.2*) - in total 200 builds per platform (80 for RHEL 9) - Tool chain: - platform gcc - CFLAGS: -O2 -g -Wall -fno-strict-aliasing All builds succeeded. - compiler warnings: - deprecation warnings when building against OpenSSL 3.1.3, see other thread Tested for - SLES 11+12+15 - RHEL 6+7+8+9 - MPMs prefork, worker, event - log level trace8 - Perl client bundle build against OpenSSL 3.1.0beta1-1, 3.0.0, 1.1.1g plus patches, 1.1.0l, 1.0.2u and 1.1.0l-1 (RHEL 9 3.1.2-1, 3.0.10-1, 1.1.1w-1) Every OpenSSL version in the client tested with every OpenSSL version in the server. 18 unit test runs (3 MPMS x 6 OpenSSL clients) per server build. About 2.400 unit test runs are done, most with server OpenSSL 3.1 and 3.0, for RHEL 9 also 1.1.1. Some local adjustments to tests were used: - t/modules/buffer.t: removing huge buffer tests -my $bigsize = 10; +my $bigsize = 5; The following test failures were seen: a t/modules/buffer.t line 37 Not a regression Only on RHEL 6, SLES 11. c t/modules/sed.t line 37 test 3 Not a regression Only on RHEL 6, SLES 11. Regards, Rainer
OpenSSL 3.0 deprecations
FYI: here's a list of symbols for which I get deprecation warnings when compiling httpd 2.4.58 (plus bundled APU) against current OpenSSL 3.1.3. or 3.0.11: srclib/apr-util/crypto/apr_crypto_openssl.c:141:5: warning: 'ENGINE_load_builtin_engines' is deprecated (declared at include/openssl/engine.h:358): Since OpenSSL 3.0 srclib/apr-util/crypto/apr_crypto_openssl.c:142:5: warning: 'ENGINE_register_all_complete' is deprecated (declared at include/openssl/engine.h:415): Since OpenSSL 3.0 srclib/apr-util/crypto/apr_crypto_openssl.c:208:9: warning: 'ENGINE_finish' is deprecated (declared at include/openssl/engine.h:628): Since OpenSSL 3.0 srclib/apr-util/crypto/apr_crypto_openssl.c:209:9: warning: 'ENGINE_free' is deprecated (declared at include/openssl/engine.h:493): Since OpenSSL 3.0 srclib/apr-util/crypto/apr_crypto_openssl.c:326:9: warning: 'ENGINE_by_id' is deprecated (declared at include/openssl/engine.h:336): Since OpenSSL 3.0 srclib/apr-util/crypto/apr_crypto_openssl.c:330:9: warning: 'ENGINE_init' is deprecated (declared at include/openssl/engine.h:620): Since OpenSSL 3.0 srclib/apr-util/crypto/apr_crypto_openssl.c:331:13: warning: 'ENGINE_free' is deprecated (declared at include/openssl/engine.h:493): Since OpenSSL 3.0 support/ab.c:769:25: warning: 'EVP_PKEY_get1_EC_KEY' is deprecated (declared at include/openssl/evp.h:1377): Since OpenSSL 3.0 support/ab.c:770:25: warning: 'EC_KEY_get0_group' is deprecated (declared at include/openssl/ec.h:1037): Since OpenSSL 3.0 support/ab.c:771:25: warning: 'EC_KEY_free' is deprecated (declared at include/openssl/ec.h:1006): Since OpenSSL 3.0 support/ab.c:1431:13: warning: 'BIO_set_callback' is deprecated (declared at include/openssl/bio.h:279): Since OpenSSL 3.0 modules/ssl/ssl_engine_config.c:611:5: warning: 'ENGINE_by_id' is deprecated (declared at include/openssl/engine.h:336): Since OpenSSL 3.0 modules/ssl/ssl_engine_config.c:613:9: warning: 'ENGINE_free' is deprecated (declared at include/openssl/engine.h:493): Since OpenSSL 3.0 modules/ssl/ssl_engine_config.c:618:9: warning: 'ENGINE_get_first' is deprecated (declared at include/openssl/engine.h:318): Since OpenSSL 3.0 modules/ssl/ssl_engine_config.c:620:13: warning: 'ENGINE_get_id' is deprecated (declared at include/openssl/engine.h:552): Since OpenSSL 3.0 modules/ssl/ssl_engine_config.c:621:42: warning: 'ENGINE_get_name' is deprecated (declared at include/openssl/engine.h:553): Since OpenSSL 3.0 modules/ssl/ssl_engine_config.c:624:13: warning: 'ENGINE_get_next' is deprecated (declared at include/openssl/engine.h:323): Since OpenSSL 3.0 modules/ssl/ssl_engine_init.c:483:9: warning: 'ENGINE_by_id' is deprecated (declared at include/openssl/engine.h:336): Since OpenSSL 3.0 modules/ssl/ssl_engine_init.c:493:13: warning: 'ENGINE_ctrl' is deprecated (declared at include/openssl/engine.h:429): Since OpenSSL 3.0 modules/ssl/ssl_engine_init.c:497:9: warning: 'ENGINE_set_default' is deprecated (declared at include/openssl/engine.h:708): Since OpenSSL 3.0 modules/ssl/ssl_engine_init.c:508:9: warning: 'ENGINE_free' is deprecated (declared at include/openssl/engine.h:493): Since OpenSSL 3.0 modules/ssl/ssl_engine_init.c:574:9: warning: 'SRP_VBASE_new' is deprecated (declared at include/openssl/srp.h:176): Since OpenSSL 3.0 modules/ssl/ssl_engine_init.c:583:9: warning: 'SRP_VBASE_init' is deprecated (declared at include/openssl/srp.h:180): Since OpenSSL 3.0 modules/ssl/ssl_engine_init.c:591:9: warning: 'SSL_CTX_set_srp_username_callback' is deprecated (declared at include/openssl/ssl.h:1900): Since OpenSSL 3.0 modules/ssl/ssl_engine_init.c:593:9: warning: 'SSL_CTX_set_srp_cb_arg' is deprecated (declared at include/openssl/ssl.h:1902): Since OpenSSL 3.0 modules/ssl/ssl_engine_init.c:1318:5: warning: 'DH_get0_p' is deprecated (declared at include/openssl/dh.h:266): Since OpenSSL 3.0 modules/ssl/ssl_engine_init.c:1539:9: warning: 'DH_free' is deprecated (declared at include/openssl/dh.h:207): Since OpenSSL 3.0 modules/ssl/ssl_engine_init.c:1556:9: warning: 'EC_KEY_new_by_curve_name' is deprecated (declared at include/openssl/ec.h:1001): Since OpenSSL 3.0 modules/ssl/ssl_engine_init.c:1578:5: warning: 'EC_KEY_free' is deprecated (declared at include/openssl/ec.h:1006): Since OpenSSL 3.0 modules/ssl/ssl_engine_init.c:1843:9: warning: 'SRP_VBASE_free' is deprecated (declared at include/openssl/srp.h:178): Since OpenSSL 3.0 modules/ssl/ssl_engine_io.c:2288:9: warning: 'BIO_set_callback' is deprecated (declared at include/openssl/bio.h:279): Since OpenSSL 3.0 modules/ssl/ssl_engine_io.c:2291:13: warning: 'BIO_set_callback' is deprecated (declared at include/openssl/bio.h:279): Since OpenSSL 3.0 modules/ssl/ssl_engine_kernel.c:545:5: warning: 'SSL_get_srp_username' is deprecated (declared at include/openssl/ssl.h:1914): Since OpenSSL 3.0 modules/ssl/ssl_engine_kernel.c:2594:13: warning: 'BIO_set_callback' is deprecated (declared at include/openssl/bio.h:279): Since OpenSSL 3.0 mod
Re: age in proxy_balancer_method
I guess it could be like this: when Mladen originally implemented the by requests load balancing method in mod_jk he used the count and subtract method for the counters. He then ported this to mod_proxy_balancer and I think it is still, how by requests counting woorks there. There are pros and cons, e.g. in case a worker goes down for some time. A bit later we switched in mod_jk to a count and divide, where division by 2 was done roughly every 60 seconds (configurable). I think the idea of the age method was roughly, that you could implement a balanvcer method, that registers a mod_watchdog task, that regularly ages the balancing counters. Aging because you want to give the past a smaller influence on the balancing decision than the more recent activity. I hope that's understandable and maybe Jim remembers something similar to that. Best regards, Rainer Am 21.12.23 um 08:23 schrieb jean-frederic clere: On 12/20/23 21:22, Jim Jagielski wrote: I'll have to go back through my notes... I do recall adding fields that although were not being used at the time, were _going to be used_ as some point, and I didn't want to have to worry about ABI compatibility. Cool I will wait before implementing something that breaks your design ;-) On Dec 14, 2023, at 8:27 AM, jean-frederic clere wrote: Hi, Any examples or docs about: apr_status_t (*age)(proxy_balancer *balancer, server_rec *s); In struct proxy_balancer_method? -- Cheers Jean-Frederic
Re: [VOTE] Release Apache httpd 2.4.11 as GA
Am 17.01.2015 um 03:58 schrieb rj...@apache.org: > Author: rjung > Date: Sat Jan 17 02:58:24 2015 > New Revision: 1652559 > > URL: http://svn.apache.org/r1652559 > Log: > Fix failing test. > > After r1651085 for mod_cgi we log cgi script > stderr to ScriptLog. Two of our test scripts > write 8KB to STDERR, each is called two times. > > So increase ScriptLogLength by 4 x 8KB, otherwise > the log file contents looked after by later tests > can not be found. > > Modified: > httpd/test/framework/trunk/t/conf/extra.conf.in > httpd/test/framework/trunk/t/modules/cgi.t I saw tests failing due to this test bug on Solaris 10 Sparc. I don't see the tests failing before this change to the test on other platforms, but those are failing now :( Reason: the stderr expected to get logged during the test to the ScriptLog does not show up in the cgi log file for those other platforms and instead goes to the normal error log - like it was normal until 2.4.10. On Solaris 10 Sparc the stderr is written to the ScriptLog by calling log_script_err() in cgi_bucket_read() (inside mod_cgi.c). On the other platforms, this piece of code isn't hit and instead the STDERR goes to the normal error log. Before change r1651085 to mod_cgi.c it always went to the normal error log. So it seems r1651085 isn't complete, but before 2.4.11 it was even more incomplete, so not really a regression. I'll take a bit of sleep now and will see, whether I can narrow down the reason for this platform specific difference later. Regards, Rainer
Re: svn commit: r1626978 - in /httpd/httpd/trunk: docs/log-message-tags/next-number modules/generators/mod_cgi.c
Hi Jan,
Am 23.09.2014 um 13:14 schrieb jkal...@apache.org:
Author: jkaluza
Date: Tue Sep 23 11:14:09 2014
New Revision: 1626978
URL: http://svn.apache.org/r1626978
Log:
mod_cgi: log cgi script stderr to ScriptLog, use APLOGNO for log_scripterror
errors.
Modified:
httpd/httpd/trunk/docs/log-message-tags/next-number
httpd/httpd/trunk/modules/generators/mod_cgi.c
...
Modified: httpd/httpd/trunk/modules/generators/mod_cgi.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/generators/mod_cgi.c?rev=1626978&r1=1626977&r2=1626978&view=diff
==
--- httpd/httpd/trunk/modules/generators/mod_cgi.c (original)
+++ httpd/httpd/trunk/modules/generators/mod_cgi.c Tue Sep 23 11:14:09 2014
...
@@ -210,8 +211,7 @@ static apr_status_t log_script_err(reque
if (newline) {
*newline = '\0';
}
-ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01215)
- "%s", argsbuffer);
+log_scripterror(r, conf, r->status, 0, APLOGNO(01215), argsbuffer);
}
return rv;
This fix and its backport to 2.4 seems to be incomplete. I can see the
STDERR output of nph-stderr.pl in the test framework now going to the
ScriptLog (after this patch, e.g. for 2.4.11) but only for some
platforms. On my Solaris 10 Sparc system it works, but on Solaris 8
Sparc or RHEL 6 the STDERR output still goes to the normal error log. I
don't expect it to be a real platform issue, but more a timing issue or
similar.
Regards,
Rainer
Re: svn commit: r1626978 - in /httpd/httpd/trunk: docs/log-message-tags/next-number modules/generators/mod_cgi.c
Am 17.01.2015 um 05:45 schrieb Rainer Jung:
Hi Jan,
Am 23.09.2014 um 13:14 schrieb jkal...@apache.org:
Author: jkaluza
Date: Tue Sep 23 11:14:09 2014
New Revision: 1626978
URL: http://svn.apache.org/r1626978
Log:
mod_cgi: log cgi script stderr to ScriptLog, use APLOGNO for
log_scripterror
errors.
Modified:
httpd/httpd/trunk/docs/log-message-tags/next-number
httpd/httpd/trunk/modules/generators/mod_cgi.c
...
Modified: httpd/httpd/trunk/modules/generators/mod_cgi.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/generators/mod_cgi.c?rev=1626978&r1=1626977&r2=1626978&view=diff
==
--- httpd/httpd/trunk/modules/generators/mod_cgi.c (original)
+++ httpd/httpd/trunk/modules/generators/mod_cgi.c Tue Sep 23 11:14:09
2014
...
@@ -210,8 +211,7 @@ static apr_status_t log_script_err(reque
if (newline) {
*newline = '\0';
}
-ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01215)
- "%s", argsbuffer);
+log_scripterror(r, conf, r->status, 0, APLOGNO(01215),
argsbuffer);
}
return rv;
This fix and its backport to 2.4 seems to be incomplete. I can see the
STDERR output of nph-stderr.pl in the test framework now going to the
ScriptLog (after this patch, e.g. for 2.4.11) but only for some
platforms. On my Solaris 10 Sparc system it works, but on Solaris 8
Sparc or RHEL 6 the STDERR output still goes to the normal error log. I
don't expect it to be a real platform issue, but more a timing issue or
similar.
The problem does not occur for mod_cgi but only for mod_cgid.
If both are being build and installed, then the test framework will load
both. It seems that for some reason my Solaris 10 Sparc system is the
only one, on which the requests are then actually executed by mod_cgi,
on all other platforms they are being executed by mod_cgid, which does
not write stderr output to the ScriptLog but instead to STDERR which is
captured by the error log.
So the fix to mod_cgi is *not* incomplete, but we should also fix it for
mod_cgid.
Regards,
Rainer
Re: [VOTE] Release Apache httpd 2.4.11 as GA
Am 15.01.2015 um 21:10 schrieb Jim Jagielski: The pre-release test tarballs for Apache httpd 2.4.11 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.11 GA. [X] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. +1 to release, thanks for RMing. In short: No regressions found. Detailed report: - Sigs and hashes OK - contents of tarballs identical - contents of tag and tarballs identical except for expected deltas (we could cleanup some m4 files in apr-util/xml/expat/conftools at the end of buildconf, no regression) Built on - Solaris 8+10 Sparc as 32 Bit Binaries - SLES 10+11 (64 Bits) - RHEL 6 (64 Bits) - with default (shared) and static modules - with module sets none, few, most, all, reallyall and default (always mod_privileges disabled) - using --enable-load-all-modules - against "included" APR/APU from deps tarball, plus external APR/APU 1.5.1/1.5.4 - using external libraries - expat 2.1.0 - pcre 8.36 - openssl 1.0.1l - lua 5.2.3 - distcache 1.5.1 - libxml2 2.9.2 - Tool chain: - platform gcc except for Solaris (gcc 4.1.2 for Solaris 8 and 4.9.1 for Solaris 10) - CFLAGS: -O2 -g -Wall -fno-strict-aliasing (and -mpcu=v9 on Solaris) All builds succeeded - three builds on RHEL had to be restarted due to crashes in the shell but that is not a regression and a platform problem - two harmless compiler warnings in modules/aaa/mod_authnz_fcgi.c Fixed now in r1652829 and proposed for 2.4 Tested for - Solaris 8+10 (32), SLES 10+11 (64), RHEL 6 (64) - MPMs prefork, worker, event (except for Solaris 8 - no event) - default (shared) and static modules - log levels info, debug and trace8 - module set reallyall (121 modules plus MPMs), "all", "most", "few", "none" and default Some combinations still run, but out of the about 900 finished combinations until now, only the following test failures were seen: a Test 4 and 5 in t/modules/dav.t: 70 runs creation, modified and now times not in the correct order. This seems to be a system issue, all tests done on NFS, many tested on virtualized guests. Not a regression. b Various tests in t/apache/expr_string.t: (3, 6, 11, 14, 20 ,23) 76 runs failed this test, (all except for one on RHEL). The failure is always on line 68, where the error_log contents are checked. Not a regression. c Tests t/modules/cgi.t testing contents of ScriptLog The tests fail for "reallyall" modules because then mod_cgi plus mod_cgid were loaded. In r1651085 logging for mod_cgi was fixed for some STDERR outputs but the test in cgi.t wasn't adjusted. So the tests fail whenever mod_cgi handles the test suite requests. On some of my systems that happened, on most of them mod_cgid came first. This was a test suite problem I hope to have fixed. We should though try to port the r1651085 enhancement from mod_cgi to mod_cgid as well (logging errors to ScriptLog instead of error log in more cases). Regards, Rainer
Re: svn commit: r1652955 - /httpd/httpd/trunk/Makefile.in
Am 19.01.2015 um 13:25 schrieb Yann Ylavic: Hi Rainer, On Mon, Jan 19, 2015 at 11:32 AM, wrote: Author: rjung Date: Mon Jan 19 10:32:51 2015 New Revision: 1652955 URL: http://svn.apache.org/r1652955 Log: PR 57379: If mod_cgi and mod_cgid get installed, use IfModule for MPM to choose mod_cgi for prefork and mod_cgid in all other cases. Previously when combined with --enable-load-all-modules both modules were loaded and it was undefined which one actually handled cgi requests. Modified: httpd/httpd/trunk/Makefile.in Indentation looks incorrect here (it should at least start with a tab). Fixed by using only tabs for the new lines and added to proposal. Note that the file also contains quite a few other (old) places where continuation lines start with space instead of tabs. Regards, Rainer
Re: [VOTE] Release Apache httpd 2.4.11 as GA
Am 19.01.2015 um 14:16 schrieb Jim Jagielski: Thx for the catch!! Looks like we need to add some additional tests to the perl test framework :) I'll keep the VOTE open, to encourage others to continue to test, but I consider 2.4.11 DOA. I took the opportunity to put 2.4.11 plus the one after-tag revert on aurora (the EU server for the www website of the ASF, server is FreeBSD 9.1). Currently running fine, no crashes, about 180 requests/s, no obvious errors. Regards, Rainer
Hanging child process during MaxConnectionsPerChild exit (event, 2.4.11)
I noticed a hanging child process on our ASF server aurora.
It currently uses 2.4.11 (plus the post tag commit) and event MPM.
Most processes exiting due to MaxConnectionsPerChild get cleaned up
after some time but this one doesn't. It now hangs for more than an
hour. I'll let it hang. In case anyone has a good question I can answer
with gdb let me know.
It shows a strange connection view in the server status table:
PID Connections Threads Async connections
total accepting busyidlewriting keep-alive closing
93557 1 yes 0 0 0 0 0
So it has 1 connection, but 0s in all other columns.
The connection can be seen by lsof:
FD TYPE DEVICE SIZE/OFF NODE NAME
txt VREG 183,3400335528 36497117 275235
/x1/www/archive.apache.org/dist/cordova/cordova-3.4.0-src.zip
9uPIPE 0xfe061ecfab60 16384->0xfe061ecfacb8
10uPIPE 0xfe061ecfacb8 0->0xfe061ecfab60
24u KQUEUE 0xfe033071be00 count=0, state=0x2
41uIPv4 0xfe01316243d00t0TCP
127.0.0.1:35849->127.0.0.1:8050 (CLOSE_WAIT)
83uIPv4 0xfe0255d08b700t0TCP
127.0.0.1:52023->127.0.0.1:8050 (CLOSE_WAIT)
108uIPv4 0xfe09990eeb700t0TCP
127.0.0.1:22532->127.0.0.1:8050 (CLOSE_WAIT)
This is the established connectioN:
110uIPv4 0xfe0255ab4b700t0TCP
192.87.106.229:http->179.206.174.192:65496 (ESTABLISHED)
And this is likely the file being served on that connection:
126rVREG 183,3400335528 36497117 275235
/x1/www/archive.apache.org/dist/cordova/cordova-3.4.0-src.zip
156uIPv4 0xfe048d0ff3d00t0TCP
127.0.0.1:26685->127.0.0.1:8050 (CLOSE_WAIT)
229uIPv4 0xfe0131d013d00t0TCP
127.0.0.1:31538->127.0.0.1:8050 (CLOSE_WAIT)
netstat shows:
Proto Recv-Q Send-Q Local Address Foreign Address(state)
tcp4 0 87650 192.87.106.229.80 179.206.174.192.65496
ESTABLISHED
so there's 87650 bytes in the send-q. Most lilely the client hans't
acked what we send.
The highest thread is in:
#0 0x000101a0887c in ?? () from /lib/libthr.so.3
No symbol table info available.
#1 0x000101a098c9 in ?? () from /lib/libthr.so.3
No symbol table info available.
#2 0x0001015d0295 in apr_thread_join (retval=0x7fffd52c,
thd=0x109410c88) at threadproc/unix/thread.c:217
stat =
thread_stat = 0xa
#3 0x000108d67a50 in join_workers (listener=0x109410c88,
threads=0x10200b400) at event.c:2110
iter = 0
i =
rv =
thread_rv = 1
#4 0x000108d6a324 in child_main (child_num_arg=3) at event.c:2299
threads = 0x2
rv = 2
ts = 0x1020a1fa8
thread_attr = 0x1020a1fc8
start_thread_id = 0x1020a1ff8
So it hangs in apr_thread_join(). From another gdb view I can see, that
the two top most frames are actually pthread_kill() and the event line
number shows, that it hangs while trying to kill the listener.
The listener itself is in:
#0 0x000101cfe4bc in kevent () from /lib/libc.so.7
No symbol table info available.
#1 0x0001015cbe79 in impl_pollset_poll (pollset=0x1020a2dc8,
timeout=, num=0x7fffef97cf88, descriptors=0x7fffef97cf68)
at poll/unix/kqueue.c:263
ret = 0
i =
j =
tv = {tv_sec = 0, tv_nsec = 1}
tvptr = 0x7fffef97c640
rv =
fd = {p = 0x123805bf0, desc_type = 6848688, reqevents = 0,
rtnevents = 0, desc = {f = 0x10201d0a0, s = 0x10201d0a0}, client_data =
0x123bd3f80}
#2 0x000108d68688 in listener_thread (thd=0x109410c88,
dummy=) at event.c:1519
workers_were_busy = 0
ep =
rc = 70007
ti =
process_slot = 3
tpool = 0x109411028
csd = 0x12ff4a0b0
ptrans = 0x12ff4a028
lr =
have_idle_worker = 0
cs =
out_pfd = 0x109411048
num = 0
timeout_interval = 10
timeout_time = 1421704478168661
now = 1421704478068663
last_log = 1421697060293018
pt =
closed = 1
listeners_disabled = 0
#3 0x000101a010a4 in ?? () from /lib/libthr.so.3
The impl_pollset_poll() has a timeout of 100ms set. Some data for the
kevent() args:
(gdb) print *pollset
$1 = {pool = 0x1020a1028, nelts = 0, nalloc = 256, flags = 19,
wakeup_pipe = {0x6174736e692d3265, 0x612e772f6c6c}, wakeup_pfd = {p
= 0x726f2e6568636170,
desc_type = 1868771175, reqevents = 26222, rtnevents = 25135, desc
= {f = 0x70695f64656e6e61, s = 0x70695f64656e6e61}, client_data =
0x666e6f632e73}, p = 0x1020a2e20,
provider = 0x1017d9480 }
(gdb) print *pollset->p
$2 = {kqueue_fd = 24, kevent = {ident = 479, filter = -1, flags = 2,
fflags = 0, data = 0, udata = 0x0}, setsize = 512, ke_set = 0x10940c028,
result_set = 0x109411028,
ring_lock = 0x1020a2e98, query_ring = {next = 0x1020a2e6
Re: Hanging child process during MaxConnectionsPerChild exit (event, 2.4.11)
Am 20.01.2015 um 00:33 schrieb Eric Covener: On Mon, Jan 19, 2015 at 5:40 PM, Rainer Jung wrote: It currently uses 2.4.11 (plus the post tag commit) and event MPM. Was it 2.4.10 previously, or earlier? 2.4.10. But since it is automatically restarted each night, I can not say for sure whether that behavior is really new. The restart at midnight GMT a few minutes ago killed the hanging process. I'll check during the next days, whether it happens again. Regards, Rainer
Re: Hanging child process during MaxConnectionsPerChild exit (event, 2.4.11)
Am 20.01.2015 um 08:45 schrieb Ruediger Pluem: On 01/19/2015 11:40 PM, Rainer Jung wrote: I noticed a hanging child process on our ASF server aurora. It currently uses 2.4.11 (plus the post tag commit) and event MPM. Most processes exiting due to MaxConnectionsPerChild get cleaned up after some time but this one doesn't. It now hangs for more than an hour. I'll let it hang. In case anyone has a good question I can answer with gdb let me know. It shows a strange connection view in the server status table: PID Connections Threads Async connections total accepting busyidlewriting keep-alive closing 93557 1 yes 0 0 0 0 0 So it has 1 connection, but 0s in all other columns. The connection can be seen by lsof: FD TYPE DEVICE SIZE/OFF NODE NAME txt VREG 183,3400335528 36497117 275235 /x1/www/archive.apache.org/dist/cordova/cordova-3.4.0-src.zip 9uPIPE 0xfe061ecfab60 16384->0xfe061ecfacb8 10uPIPE 0xfe061ecfacb8 0->0xfe061ecfab60 24u KQUEUE 0xfe033071be00 count=0, state=0x2 41uIPv4 0xfe01316243d00t0TCP 127.0.0.1:35849->127.0.0.1:8050 (CLOSE_WAIT) 83uIPv4 0xfe0255d08b700t0TCP 127.0.0.1:52023->127.0.0.1:8050 (CLOSE_WAIT) 108uIPv4 0xfe09990eeb700t0TCP 127.0.0.1:22532->127.0.0.1:8050 (CLOSE_WAIT) This is the established connectioN: 110uIPv4 0xfe0255ab4b700t0TCP 192.87.106.229:http->179.206.174.192:65496 (ESTABLISHED) And this is likely the file being served on that connection: 126rVREG 183,3400335528 36497117 275235 /x1/www/archive.apache.org/dist/cordova/cordova-3.4.0-src.zip 156uIPv4 0xfe048d0ff3d00t0TCP 127.0.0.1:26685->127.0.0.1:8050 (CLOSE_WAIT) 229uIPv4 0xfe0131d013d00t0TCP 127.0.0.1:31538->127.0.0.1:8050 (CLOSE_WAIT) netstat shows: Proto Recv-Q Send-Q Local Address Foreign Address(state) tcp4 0 87650 192.87.106.229.80 179.206.174.192.65496 ESTABLISHED so there's 87650 bytes in the send-q. Most lilely the client hans't acked what we send. Isn't it weird that the connection remains in this state for an hour? I would guess the OS tries to resent whats in the buffer and if doesn't get ACK'ed it would somehow timeout the TCP connection and assume the peer is gone. I was misguided by the server-status table. I have another child process now with one open connection, all zeroes in the other server status columns and for that I checked network and process activity. And indeed ktrace and tcpdump both show, that the process still does send some data every few seconds. It just takes very long for the big file served and the low rate of transfer. Thanks for putting me on the right track. I will check for a few more "hanging" children during the next days whether they actually still serve files. So it all boils down to why the connection isn't shown in any of the state columns in the server status table. Plus it could be interesting to limit the time a closing child still serves requests, because it keeps blocking a scoreboard entry and aborting one or two requests every now and them might be better than running out of children. Regards, Rainer
Re: Hanging child process during MaxConnectionsPerChild exit (event, 2.4.11)
Am 20.01.2015 um 10:15 schrieb Rainer Jung: Am 20.01.2015 um 08:45 schrieb Ruediger Pluem: On 01/19/2015 11:40 PM, Rainer Jung wrote: I noticed a hanging child process on our ASF server aurora. It currently uses 2.4.11 (plus the post tag commit) and event MPM. Most processes exiting due to MaxConnectionsPerChild get cleaned up after some time but this one doesn't. It now hangs for more than an hour. I'll let it hang. In case anyone has a good question I can answer with gdb let me know. It shows a strange connection view in the server status table: PID Connections Threads Async connections total accepting busyidlewriting keep-alive closing 93557 1 yes 0 0 0 0 0 So it has 1 connection, but 0s in all other columns. The connection can be seen by lsof: FD TYPE DEVICE SIZE/OFF NODE NAME txt VREG 183,3400335528 36497117 275235 /x1/www/archive.apache.org/dist/cordova/cordova-3.4.0-src.zip 9uPIPE 0xfe061ecfab60 16384->0xfe061ecfacb8 10uPIPE 0xfe061ecfacb8 0->0xfe061ecfab60 24u KQUEUE 0xfe033071be00 count=0, state=0x2 41uIPv4 0xfe01316243d00t0TCP 127.0.0.1:35849->127.0.0.1:8050 (CLOSE_WAIT) 83uIPv4 0xfe0255d08b700t0TCP 127.0.0.1:52023->127.0.0.1:8050 (CLOSE_WAIT) 108uIPv4 0xfe09990eeb700t0TCP 127.0.0.1:22532->127.0.0.1:8050 (CLOSE_WAIT) This is the established connectioN: 110uIPv4 0xfe0255ab4b700t0TCP 192.87.106.229:http->179.206.174.192:65496 (ESTABLISHED) And this is likely the file being served on that connection: 126rVREG 183,3400335528 36497117 275235 /x1/www/archive.apache.org/dist/cordova/cordova-3.4.0-src.zip 156uIPv4 0xfe048d0ff3d00t0TCP 127.0.0.1:26685->127.0.0.1:8050 (CLOSE_WAIT) 229uIPv4 0xfe0131d013d00t0TCP 127.0.0.1:31538->127.0.0.1:8050 (CLOSE_WAIT) netstat shows: Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 87650 192.87.106.229.80 179.206.174.192.65496 ESTABLISHED so there's 87650 bytes in the send-q. Most lilely the client hans't acked what we send. Isn't it weird that the connection remains in this state for an hour? I would guess the OS tries to resent whats in the buffer and if doesn't get ACK'ed it would somehow timeout the TCP connection and assume the peer is gone. I was misguided by the server-status table. I have another child process now with one open connection, all zeroes in the other server status columns and for that I checked network and process activity. And indeed ktrace and tcpdump both show, that the process still does send some data every few seconds. It just takes very long for the big file served and the low rate of transfer. Thanks for putting me on the right track. I will check for a few more "hanging" children during the next days whether they actually still serve files. So it all boils down to why the connection isn't shown in any of the state columns in the server status table. Plus it could be interesting to limit the time a closing child still serves requests, because it keeps blocking a scoreboard entry and aborting one or two requests every now and them might be better than running out of children. And now another hour later, the same process actually shows the connection in the "Async connection - writing" column. Even more confusing. I wonder in which state the connection was in between. Regards, Rainer
Re: Hanging child process during MaxConnectionsPerChild exit (event, 2.4.11)
Hi Jim, let this observation not stop you from tagging 2.4.12. I don't think it is new behavior and in contrast to my original expectation the child processes do not hang infinitely but instead just serve the remaining requests with a low data send rate. The only strange thing - and that is likely not new - is that the remaining connection(s) often are not counted in the busy or async connections columns in server-status. Regards, Rainer Am 20.01.2015 um 12:52 schrieb Jim Jagielski: Isn't the TCP keepalive like 2hours or so? On Jan 20, 2015, at 2:45 AM, Ruediger Pluem wrote: On 01/19/2015 11:40 PM, Rainer Jung wrote: I noticed a hanging child process on our ASF server aurora. It currently uses 2.4.11 (plus the post tag commit) and event MPM. Most processes exiting due to MaxConnectionsPerChild get cleaned up after some time but this one doesn't. It now hangs for more than an hour. I'll let it hang. In case anyone has a good question I can answer with gdb let me know. It shows a strange connection view in the server status table: PID Connections Threads Async connections total accepting busyidlewriting keep-alive closing 93557 1 yes 0 0 0 0 0 So it has 1 connection, but 0s in all other columns. The connection can be seen by lsof: FD TYPE DEVICE SIZE/OFF NODE NAME txt VREG 183,3400335528 36497117 275235 /x1/www/archive.apache.org/dist/cordova/cordova-3.4.0-src.zip 9uPIPE 0xfe061ecfab60 16384->0xfe061ecfacb8 10uPIPE 0xfe061ecfacb8 0->0xfe061ecfab60 24u KQUEUE 0xfe033071be00 count=0, state=0x2 41uIPv4 0xfe01316243d00t0TCP 127.0.0.1:35849->127.0.0.1:8050 (CLOSE_WAIT) 83uIPv4 0xfe0255d08b700t0TCP 127.0.0.1:52023->127.0.0.1:8050 (CLOSE_WAIT) 108uIPv4 0xfe09990eeb700t0TCP 127.0.0.1:22532->127.0.0.1:8050 (CLOSE_WAIT) This is the established connectioN: 110uIPv4 0xfe0255ab4b700t0TCP 192.87.106.229:http->179.206.174.192:65496 (ESTABLISHED) And this is likely the file being served on that connection: 126rVREG 183,3400335528 36497117 275235 /x1/www/archive.apache.org/dist/cordova/cordova-3.4.0-src.zip 156uIPv4 0xfe048d0ff3d00t0TCP 127.0.0.1:26685->127.0.0.1:8050 (CLOSE_WAIT) 229uIPv4 0xfe0131d013d00t0TCP 127.0.0.1:31538->127.0.0.1:8050 (CLOSE_WAIT) netstat shows: Proto Recv-Q Send-Q Local Address Foreign Address(state) tcp4 0 87650 192.87.106.229.80 179.206.174.192.65496 ESTABLISHED so there's 87650 bytes in the send-q. Most lilely the client hans't acked what we send. Isn't it weird that the connection remains in this state for an hour? I would guess the OS tries to resent whats in the buffer and if doesn't get ACK'ed it would somehow timeout the TCP connection and assume the peer is gone. Regards Rüdiger
Re: [VOTE] Release Apache httpd 2.4.12 as GA
Am 26.01.2015 um 14:14 schrieb Eric Covener: On Mon, Jan 26, 2015 at 8:08 AM, Jim Jagielski wrote: svn diff https://svn.apache.org/repos/asf/httpd/httpd/tags/2.4.11 https://svn.apache.org/repos/asf/httpd/httpd/tags/2.4.12 | cdiff first one should be 2.4.10 (not that it turns up anything better) What about APR changes? I checked the logs of my about 1000 runs of the test suite with various MPMs and log levels and on various platforms and did not find a single entry with wrong timezone. I also checked the access logs of the two ASF httpd instance which I had updated to 2.4.12 yesterday. Those run on GMT timezone, so checking the offset made no sense, but I was looking for timestamps which were out of the expected range w.r.t. neighboring entries and their own duration. For the www instance using the event MPM I could not find such entries. For the mail-archives instance using the prefork MPM I found some entries. For example two entries apparently logged at 01:02 but containing a timestamp of 00:02. But the same process/connection had its previous requests being handled at 00:02, so it seems the two requests were somehow written delayed or finishing the request was delayed. The request duration (%D) was small though. The same observation holds for older versions, e.g. 2.4.10. I do find such constellations there as well. Would be interesting to know why it happens, but IMHO not a show-stopper or a regression. At least not the cases on these instances. But those only partially fit the pattern observed by Noel. Regards, Rainer
Re: [VOTE] Release Apache httpd 2.4.12 as GA
Am 22.01.2015 um 19:54 schrieb Jim Jagielski: The pre-release test tarballs for Apache httpd 2.4.12 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.12 GA. [X] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. +1 to release, thanks for RMing. In short: No regressions found. Detailed report: - Sigs and hashes OK - contents of tarballs identical - contents of tag and tarballs identical except for expected deltas (we could cleanup some m4 files in apr-util/xml/expat/conftools at the end of buildconf, no regression) Built on - Solaris 8+10 Sparc as 32 Bit Binaries - SLES 10+11 (64 Bits) - RHEL 6 (64 Bits) - FreeBSD 9.1 On FreeBSD 2.4.12 runs on one machine for the ASF the www and mail-archives httpd instances. No problems showed up. For all platforms except FreeBSD built - with default (shared) and static modules - with module sets none, few, most, all, reallyall and default (always mod_privileges disabled) - using --enable-load-all-modules - against "included" APR/APU from deps tarball, plus external APR/APU 1.5.1/1.5.4 - using external libraries - expat 2.1.0 - pcre 8.36 - openssl 1.0.1l - lua 5.2.3 - distcache 1.5.1 - libxml2 2.9.2 - Tool chain: - platform gcc except for Solaris (gcc 4.1.2 for Solaris 8 and 4.9.1 for Solaris 10) - CFLAGS: -O2 -g -Wall -fno-strict-aliasing (and -mpcu=v9 on Solaris) All builds succeeded - two harmless compiler warnings in modules/aaa/mod_authnz_fcgi.c Fixed in r1652829 and proposed for 2.4 Tested for - Solaris 8+10 (32), SLES 11 (64), RHEL 6 (64) - MPMs prefork, worker, event (except for Solaris 8 - no event) - default (shared) and static modules - log levels info, debug and trace8 - module set reallyall (121 modules plus MPMs), "all", "most", "few", "none" and default I didn't wait for finishing all combinations, but out of the about 1050 finished combinations, only the following test failures were seen: a Test 4 and 5 in t/modules/dav.t: 50 runs. Creation, modified and now times not in the correct order. This seems to be a system issue, all tests done on NFS, many tested on virtualized guests. Not a regression. b Various tests in t/apache/expr_string.t: (3, 6, 11, 14, 20 ,23) 33 runs failed this test, (all except for two on RHEL). The failure is always on line 68, where the error_log contents are checked. Not a regression. c Tests 55-57 of t/modules/cgi.t testing contents of ScriptLog. The tests fail for "reallyall" modules and static builds because then mod_cgi plus mod_cgid are loaded both. After r1651085 STDERR logging for mod_cgi and mod_cgid behave differently and cgi.t doesn't know which of the two loaded modules actually handles the request. This was a test suite problem. It happens on most platforms but not on Solaris 10, lilkely due to a different hook sort order of mod_cgi and mod_cgid there. We should try to port the r1651085 enhancement from mod_cgi to mod_cgid as well (logging errors to ScriptLog instead of error log in more cases). Regards, Rainer
Re: [VOTE] Release Apache httpd 2.4.12 as GA
Am 27.01.2015 um 21:41 schrieb William A. Rowe Jr.: I'd agree. My thoughts on OP's posts, that their specific PHP scripts are modifying the global timezone locale, notably process-by-process, and these are not reset at the end of processing. In the case of the event or worker MPM it's impossible to do this without a thread-local implementation of time.h (as Windows and Netware have long had) while even with prefork, depending on which process handles a given request, this php script will apparently have left the server in one state or another, leading to 'flipping' the timezone from log entry to entry. But wasn't the time itself also wrong? I had the impression the observation was not only about timezone, but wrong timezone was easiest to detect. I could be wrong but it looked like the timezone shift would not have explained the change in time stamp in the same log entries. It's [mostly] harmless. If a given log entry is 'zinged' by a change of the timezone offset in between formatting the zone and formatting the time and the date, this could yield some wild jumps. But as the PHP crew long demoted thread saftey from experimental to deprecated (IIUC), then I'm afraid we simply have to take them at their word. The universally endorsed php processing mechanism is now fcgi. There is a possibility that OP's had actually rebuilt APR (from the -deps), even with the very same APR version, which resulting in some different autoconf detection on their platform relative to time.h function handling. It would be worth close inspection of their own config.cache files of old and new APR builds to say for sure. Regards, Rainer
Re: [VOTE] Release Apache httpd 2.4.12 as GA
Am 28.01.2015 um 23:01 schrieb William A. Rowe Jr.: On Wed, 28 Jan 2015 12:02:32 +0100 Rainer Jung wrote: Am 27.01.2015 um 21:41 schrieb William A. Rowe Jr.: I'd agree. My thoughts on OP's posts, that their specific PHP scripts are modifying the global timezone locale, notably process-by-process, and these are not reset at the end of processing. In the case of the event or worker MPM it's impossible to do this without a thread-local implementation of time.h (as Windows and Netware have long had) while even with prefork, depending on which process handles a given request, this php script will apparently have left the server in one state or another, leading to 'flipping' the timezone from log entry to entry. But wasn't the time itself also wrong? I had the impression the observation was not only about timezone, but wrong timezone was easiest to detect. I could be wrong but it looked like the timezone shift would not have explained the change in time stamp in the same log entries. I reviewed Noel's comments; 170.130.179.246 - - [26/Jan/2015:01:02:06 +] "GET /archives/ 197.156.95.99 - - [26/Jan/2015:11:02:18 +1000] "GET /ups/t568b.png HTTP/1.1" 95.211.138.225 - - [26/Jan/2015:01:02:40 +] "GET /Android-Apps.html HTTP/1.1" 144.76.247.107 - - [26/Jan/2015:11:03:32 +1000] "GET / (correct time is 11:xx:xx) I presume he means 1100 hours, GMT +10. If that is the case then the 0100 hours entries are also correct relative to Zulu, GMT +/- 0. Ah, sorry I had read +0100 and not +1000. Yes, you are right. Regards, Rainer
Re: Backporting features from 2.4 to 2.2
Hi, Am 08.02.2015 um 01:48 schrieb Davis: Is backporting of configuration parameters SSLSessionTicketKeyFile and SSLSessionTickets to 2.2 branch welcome? SSLSessionTickets for 2.2 has already been backported by Yann: http://people.apache.org/~ylavic/httpd-2.2.x-SSLSessionTickets.patch It is on vote in the STATUS file for 2.2 and only needs a third committer vote to get applied to 2.2. For SSLSessionTicketKeyFile IMHO yes, welcome, but maybe you have to be careful because 2.2 is expected to support older OpenSSL than 2.4. I haven't checked whether backporting is easy or not. Regards, Rainer
Re: svn commit: r1657685 - /httpd/httpd/trunk/server/util_expr_eval.c
Hi Yann,
Am 24.02.2015 um 12:51 schrieb Yann Ylavic:
Hi,
On Thu, Feb 5, 2015 at 9:33 PM, wrote:
Author: rjung
Date: Thu Feb 5 20:33:59 2015
New Revision: 1657685
URL: http://svn.apache.org/r1657685
[...]
Modified:
httpd/httpd/trunk/server/util_expr_eval.c
Modified: httpd/httpd/trunk/server/util_expr_eval.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_expr_eval.c?rev=1657685&r1=1657684&r2=1657685&view=diff
==
--- httpd/httpd/trunk/server/util_expr_eval.c (original)
+++ httpd/httpd/trunk/server/util_expr_eval.c Thu Feb 5 20:33:59 2015
[...]
@@ -113,6 +114,30 @@ static const char *ap_expr_eval_word(ap_
else
result = apr_pstrcat(ctx->p, s1, s2, NULL);
}
+else if (((ap_expr_t *)node->node_arg1)->node_op == op_Concat) {
+const ap_expr_t *nodep = node;
+int n;
+int i = 1;
+struct iovec *vec;
+do {
+nodep = nodep->node_arg1;
+i++;
+} while (nodep->node_op == op_Concat);
+vec = apr_palloc(ctx->p, i * sizeof(struct iovec));
+n = i;
+nodep = node;
+i--;
+do {
+vec[i].iov_base = (void *)ap_expr_eval_word(ctx,
+nodep->node_arg2);
+vec[i].iov_len = strlen(vec[i].iov_base);
+i--;
+nodep = nodep->node_arg1;
+} while (nodep->node_op == op_Concat);
+vec[i].iov_base = (void *)ap_expr_eval_word(ctx, nodep);
+vec[i].iov_len = strlen(vec[i].iov_base);
+result = apr_pstrcatv(ctx->p, vec, n, NULL);
+}
else {
Why concatenating in reverse order here?
Because first doing it in normal order produced a reverse result and my
paper computer then showed reverse is correct :)
Assume the tree looks like (left is node1, right node2):
concat
concat r1
concat r2
l1 r3
Result should be l1r3r2r1, so the r's need reverse order.
Actually, I cannot manage to test this because I'm not able to find an
expression that produces node_arg1->node_op == op_Concat.
Due to the %right association of T_OP_CONCAT in the parser/yacc, "'x'
. 'y' . 'z'" gives "concat( 'x', concat ('y, 'z'))", which is
node_arg1->node_op == op_String and node_arg2->node_op == op_Concat...
Can you please share an expression for the new branch to be taken?
The problem (recursion limit reached because the previous optimization
didn't apply) occurred for me with string expressions (not boolean) of
the form
"constant1%{function1:arg1}constant2%{function2:arg2}constant3%{function3:arg3}..."
For example in 2.4 use mod_log_debug and the following config:
LogLevel info
LogMessage
"|%{HTTPS}|%{HTTPS}|%{HTTPS}|%{HTTPS}|%{HTTPS}|%{HTTPS}|%{HTTPS}|%{HTTPS}|%{HTTPS}|%{HTTPS}|%{HTTPS}|%{HTTPS}|%{HTTPS}|%{HTTPS}|%{HTTPS}"
Without the patch the error log contains:
[Tue Feb 24 14:06:48.913709 2015] [log_debug:error] [pid 3664:tid 22]
[client 127.0.0.1:48807] Evaluation of expression from
/.../conf/httpd.conf:563 failed: Recursion limit reached
[Tue Feb 24 14:06:48.913805 2015] [log_debug:error] [pid 3664:tid 22]
[client 127.0.0.1:48807] AH00641: Can't evaluate message expression:
Recursion limit reached
[Tue Feb 24 14:06:48.913827 2015] [log_debug:info] [pid 3664:tid 22]
[client 127.0.0.1:48807] (null)
With the patch you get:
[Tue Feb 24 14:10:50.497472 2015] [log_debug:info] [pid 8785:tid 27]
[client 127.0.0.1:48817]
|off|off|off|off|off|off|off|off|off|off|off|off|off|off|off
Thank you for your careful review!
Regards,
Rainer
Re: svn commit: r1634520 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS docs/manual/rewrite/advanced.xml modules/proxy/proxy_util.c
Am 23.01.2015 um 11:09 schrieb Yann Ylavic: On Mon, Oct 27, 2014 at 1:40 PM, wrote: Author: jim Date: Mon Oct 27 12:40:34 2014 New Revision: 1634520 URL: http://svn.apache.org/r1634520 Log: Merge r1621367, r1621372, r1625952 from trunk: PR53218 Allow for longer worker names and make truncation a non-fatal error... Correct loglevel. oops... prepend 0 Reviewed/backported by: jim Modified: httpd/httpd/branches/2.4.x/ (props changed) httpd/httpd/branches/2.4.x/CHANGES httpd/httpd/branches/2.4.x/STATUS httpd/httpd/branches/2.4.x/docs/manual/rewrite/advanced.xml (props changed) httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c The "modules/proxy/mod_proxy.h" part of r1621367 was not merge here, ie : --- httpd/httpd/trunk/modules/proxy/mod_proxy.h (original) +++ httpd/httpd/trunk/modules/proxy/mod_proxy.h Fri Aug 29 19:17:45 2014 @@ -317,7 +317,7 @@ PROXY_WORKER_DISABLED | PROXY_WORKER_STO #define PROXY_WORKER_MAX_SCHEME_SIZE 16 #define PROXY_WORKER_MAX_ROUTE_SIZE 96 #define PROXY_BALANCER_MAX_ROUTE_SIZE64 -#define PROXY_WORKER_MAX_NAME_SIZE 96 +#define PROXY_WORKER_MAX_NAME_SIZE 192 #define PROXY_BALANCER_MAX_NAME_SIZE 64 #define PROXY_WORKER_MAX_HOSTNAME_SIZE 96 #define PROXY_BALANCER_MAX_HOSTNAME_SIZE 64 So the worker name is still 96 bytes (max) in 2.4.x. This hasn't changed yet.
Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h
Hi Stefan,
Am 01.04.2015 um 18:22 schrieb Stefan Eissing:
Jim,
today I converted your commit to a path on 2.4.12 and tested it with mod_h2.
All fine!
Then I got a trouble report that alpn negotiation always selected "http/1.1" unless SSLAlpnPreference
configured something else. This is due to the deterministic ordering and "http/1.1." >
"h2". So, I made a slight modification, attached below.
Maybe related but concerning NPN: There was a difference between the NPN
parts of your original Bugzilla attachment and what was already in
mod_ssl trunk and therefore was not applied. In your attachment, there
was some code for sorting in ssl_callback_AdvertiseNextProtos() which
IMHO does not exist in trunk. Is that part necessary?
A second difference: your original addition to ssl_engine_io.c had the
NPN and the ALPN parts merged in the same code block. In trunk those are
now two separate pieces coming after each other.
--- modules/ssl/ssl_engine_kernel.c 2015-04-01 15:23:48.0 +0200
+++ ../../mod-h2/sandbox/httpd/gen/httpd-2.4.12/modules/ssl/ssl_engine_kernel.c
2015-04-01 17:53:03.0 +0200
@@ -2177,7 +2152,7 @@
}
/*
- * Compare to ALPN protocol proposal. Result is similar to strcmp():
+ * Compare two ALPN protocol proposal. Result is similar to strcmp():
* 0 gives same precedence, >0 means proto1 is prefered.
*/
static int ssl_cmp_alpn_protos(modssl_ctx_t *ctx,
@@ -2254,14 +2229,8 @@
i += plen;
}
-/* Regardless of installed hooks, the http/1.1 protocol is always
- * supported by us. Add it to the proposals if the client also
- * offers it. */
proposed_protos = apr_array_make(c->pool, client_protos->nelts+1,
sizeof(char *));
-if (ssl_array_index(client_protos, alpn_http1) >= 0) {
-APR_ARRAY_PUSH(proposed_protos, const char*) = alpn_http1;
-}
if (sslconn->alpn_proposefns != NULL) {
/* Invoke our alpn_propos_proto hooks, giving other modules a chance
to
@@ -2280,9 +2249,16 @@
}
if (proposed_protos->nelts <= 0) {
-ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
- "none of the client alpn protocols are supported");
-return SSL_TLSEXT_ERR_ALERT_FATAL;
+/* Regardless of installed hooks, the http/1.1 protocol is always
+ * supported by us. Choose it if none other matches. */
+if (ssl_array_index(client_protos, alpn_http1) < 0) {
+ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
+ "none of the client alpn protocols are supported");
+return SSL_TLSEXT_ERR_ALERT_FATAL;
+}
+*out = (const unsigned char*)alpn_http1;
+*outlen = (unsigned char)strlen(alpn_http1);
+return SSL_TLSEXT_ERR_OK;
}
/* Now select the most preferred protocol from the proposals. */
Re: svn commit: r1673470 - /httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml
Am 14.04.2015 um 19:06 schrieb rbo...@apache.org: Author: rbowen Date: Tue Apr 14 17:06:10 2015 New Revision: 1673470 URL: http://svn.apache.org/r1673470 Log: Add "pre-compressed content" recipe, as per https://bz.apache.org/bugzilla/show_bug.cgi?id=51336 Modified: httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml Modified: httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml?rev=1673470&r1=1673469&r2=1673470&view=diff == --- httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml (original) +++ httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml Tue Apr 14 17:06:10 2015 @@ -178,6 +178,51 @@ SetEnvIfNoCase Request_URI \.(?:gif|jpe? +Serving pre-compressed +content + +Since mod_deflate re-compresses content each +time a request is made, some performance benefit can be derived by +pre-compressing the content and telling mod_deflate to serve them +without re-compressing them. This may be accomplished using a +configuration like the following: + + ++# Serve gzip compressed CSS files if they exist +# and the client accepts gzip. +RewriteCond %{HTTP:Accept-encoding} gzip +RewriteCond %{REQUEST_FILENAME}\.gz -s +RewriteRule ^(.*)\.css $1\.css\.gz [QSA] + +# Serve gzip compressed JS files if they exist +# and the client accepts gzip. +RewriteCond %{HTTP:Accept-encoding} gzip +RewriteCond %{REQUEST_FILENAME}\.gz -s +RewriteRule ^(.*)\.js $1\.js\.gz [QSA] + + +# Serve correct content types, and prevent mod_deflate double gzip. +RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1] +RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1] + + + + + + + + + + DeflateFilterNote Places the compression ratio in a note for logging AFAIK mod_rewrite automatically adds headers from RewriteCond to the Vary header as long as no "NV" flag is used. So the "Header append Vary Accept-Encoding" part should not be necessary. Thanks for putting effort into documenting the recipe. Regards, Rainer+ # Serve correct encoding type. + Header append Content-Encoding gzip + + # Force proxies to cache gzipped & + # non-gzipped css/js files separately. + Header append Vary Accept-Encoding + +
Re: svn commit: r1673470 - /httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml
Am 15.04.2015 um 00:14 schrieb Rainer Jung:
Am 14.04.2015 um 19:06 schrieb rbo...@apache.org:
Author: rbowen
Date: Tue Apr 14 17:06:10 2015
New Revision: 1673470
URL: http://svn.apache.org/r1673470
Log:
Add "pre-compressed content" recipe, as per
https://bz.apache.org/bugzilla/show_bug.cgi?id=51336
Modified:
httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml
Modified: httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml?rev=1673470&r1=1673469&r2=1673470&view=diff
==
--- httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_deflate.xml Tue Apr 14
17:06:10 2015
@@ -178,6 +178,51 @@ SetEnvIfNoCase Request_URI \.(?:gif|jpe?
+Serving pre-compressed
+content
+
+Since mod_deflate re-compresses content each
+time a request is made, some performance benefit can be derived by
+pre-compressing the content and telling mod_deflate to serve them
+without re-compressing them. This may be accomplished using a
+configuration like the following:
+
+
+ <IfModule mod_headers.c>
+# Serve gzip compressed CSS files if they exist
+# and the client accepts gzip.
+RewriteCond %{HTTP:Accept-encoding} gzip
+RewriteCond %{REQUEST_FILENAME}\.gz -s
+RewriteRule ^(.*)\.css $1\.css\.gz [QSA]
+
+# Serve gzip compressed JS files if they exist
+# and the client accepts gzip.
+RewriteCond %{HTTP:Accept-encoding} gzip
+RewriteCond %{REQUEST_FILENAME}\.gz -s
+RewriteRule ^(.*)\.js $1\.js\.gz [QSA]
+
+
+# Serve correct content types, and prevent mod_deflate double gzip.
+RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
+RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]
+
+
+<FilesMatch "(\.js\.gz|\.css\.gz)$">
+ # Serve correct encoding type.
+ Header append Content-Encoding gzip
+
+ # Force proxies to cache gzipped &
+ # non-gzipped css/js files separately.
+ Header append Vary Accept-Encoding
+</FilesMatch>
+ </IfModule>
+
+
+
+
+
+
+
DeflateFilterNote
Places the compression ratio in a note for
logging
AFAIK mod_rewrite automatically adds headers from RewriteCond to the
Vary header as long as no "NV" flag is used. So the "Header append Vary
Accept-Encoding" part should not be necessary.
I should probably also mention, that the recipe gets easier, once one
accepts a non-standard convention for the names of the compressed
content. If you add the ".gz" before the final suffix ".js", ".css"
etc., then the web server will automatically get the content type
correct. So you can drop the "T=" flags. My variant of the recipe was:
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME} ^(.+)\.(css|js)$
RewriteCond %1.gz%2 -s
RewriteRule ^(.+)\.(css|js)$ $1.gz.$2 [QSA,E=gz:1,E=no-gzip:1]
Header append Content-Encoding gzip env=gz
The additional replacement of FilesMatch with a custom env var (here
named "gz") one can check in the "Header append" part is independent of
the other change.
One could drop the second and third RewriteCond, if one assumes that all
such files have been compressed. To create the compressed files with
non-standard name convention, one can use on Unix/Linux a script like e.g.
CONTENT_DIR=/opt/myapp/static/
PERMS=644
for suffix in css js
do
for file in \
`find $CONTENT_DIR -type f -name "*.$suffix" -a ! -name "*.gz.*"`
do
gzfile=`echo $file | sed -e 's#\.'$suffix'#.gz.'$suffix'#'`
gzip --best -c $file > $gzfile
chmod $PERMS $gzfile
echo === $file $gzfile ===
ls -ld $file $gzfile
done
done
I like the idea of adding this as a feature to mod_deflate. I actually
started doing this a few weeks ago but got side-tracked.
Regards,
Rainer
Re: svn commit: r1673940 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/ssl/ssl_util_ssl.c
Am 15.04.2015 um 21:49 schrieb cove...@apache.org: Author: covener Date: Wed Apr 15 19:49:31 2015 New Revision: 1673940 URL: http://svn.apache.org/r1673940 Log: Merge r1666297 from trunk: ssl_util: Fix possible crash (free => OPENSSL_free) and error path leaks when checking the server certificate constraints (SSL_X509_getBC()). Modified: httpd/httpd/branches/2.4.x/ (props changed) httpd/httpd/branches/2.4.x/CHANGES httpd/httpd/branches/2.4.x/STATUS httpd/httpd/branches/2.4.x/modules/ssl/ssl_util_ssl.c Modified: httpd/httpd/branches/2.4.x/CHANGES URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CHANGES?rev=1673940&r1=1673939&r2=1673940&view=diff == --- httpd/httpd/branches/2.4.x/CHANGES [utf-8] (original) +++ httpd/httpd/branches/2.4.x/CHANGES [utf-8] Wed Apr 15 19:49:31 2015 @@ -12,6 +12,13 @@ Changes with Apache 2.4.13 calls r:wsupgrade() can cause a child process crash. [Edward Lu ] + *) mod_ssl: Fix possible crash when loading server certificate constraints. + PR 57694. [Paul Spangler , Yann Ylavic] + + *) core, modules: Avoid error response/document handling by the core if some + handler or input filter already did it while reading the request (causing + a double response body). [Yann Ylavic] + *) build: Don't load mod_cgi and mod_cgid in the default configuration if they're both built. [olli hauer ] Is the second (core) entry intentional or a merge error? Regards, Rainer
Re: ALPN patch comments
Am 22.04.2015 um 17:49 schrieb Kaspar Brand: On 22.04.2015 10:52, Stefan Eissing wrote: I made two small patches based on the feedback from Kaspar. One for the code and one for the documentation. Thanks. In the patch for ssl_private.h, the complete NPN block should actually be dropped - the same block is are already part of ssl_private.h, just 10 lines above. I've kept the new one and dropped the old one in r1675459. The condition was slightly different. I dropped #if !defined(OPENSSL_NO_NEXTPROTONEG) && defined(OPENSSL_NPN_NEGOTIATED) and kept #if !defined(OPENSSL_NO_NEXTPROTONEG) && !defined(OPENSSL_NO_TLSEXT) && defined(OPENSSL_NPN_NEGOTIATED) Hope that's OK. Regards, Rainer
Re: ALPN patch comments
Am 23.04.2015 um 06:56 schrieb Kaspar Brand: On 22.04.2015 21:30, Rainer Jung wrote: Am 22.04.2015 um 17:49 schrieb Kaspar Brand: Thanks. In the patch for ssl_private.h, the complete NPN block should actually be dropped - the same block is are already part of ssl_private.h, just 10 lines above. I've kept the new one and dropped the old one in r1675459. It's nitpicking, but... the old one was already correct, actually. All this stuff is in a larger "#if !defined(OPENSSL_NO_TLSEXT) ..." block, so there's no need to repeat NO_TLSEXT. Oups, fixed in r1675549. I'd rather get consensus on completely dropping HAVE_TLS_NPN from trunk anyway, though, so it's really a very minor point right now ;-) Agreed. Rainer
Re: svn commit: r1680895 - in /httpd/httpd/trunk: docs/manual/mod/mod_log_config.xml modules/loggers/mod_log_config.c
Am 21.05.2015 um 20:57 schrieb Eric Covener: On Thu, May 21, 2015 at 2:54 PM, Jeff Trawick wrote: This is a very nice improvement over introducing "M", and Yann's suggestion to expand "T" instead of "D" is an increment above that. Any concerns if I switch them out? +1 here No concern. I'm just to lazy to do it myself after goind down the %D route. Go ahead if you like. Most of us seem to favor it. Regards, Rainer
Two questions on mod_ssl source code details
1) In other code I see EC_KEY_free(ecdh); after EC_KEY *ecdh = EC_KEY_new_by_curve_name(...) and using ecdh, e.g. in SSL_CTX_set_tmp_ecdh(mctx->ssl_ctx, eckey); Should we add the free? Or is it not needed? Anyone knows why? 2) In modules/ssl/ssl_private.h I see /** * The following features all depend on TLS extension support. * Within this block, check again for features (not version numbers). */ #if !defined(OPENSSL_NO_TLSEXT) && defined(SSL_set_tlsext_host_name) #define HAVE_TLSEXT and then further checks and defines for OCSP, Session Tickets, SRP, ALPN, all inside this "if" block. Is it really true, that they are only supported if SSL_set_tlsext_host_name is defined? That function seems to belong only to SNI. Should we switch the code to: /** * The following features all depend on TLS extension support. * Within this block, check again for features (not version numbers). */ #if !defined(OPENSSL_NO_TLSEXT) #define HAVE_TLSEXT #if defined(SSL_set_tlsext_host_name) #define HAVE_SNI #endif and then use HAVE_SNI where appropriate. Regards, Rainer
Re: Two questions on mod_ssl source code details
1) In other code I see EC_KEY_free(ecdh); after EC_KEY *ecdh = EC_KEY_new_by_curve_name(...) and using ecdh, e.g. in SSL_CTX_set_tmp_ecdh(mctx->ssl_ctx, eckey); Should we add the free? Or is it not needed? Anyone knows why? This was added in r1666363: * mod_ssl: fix small memory leak in ssl_init_server_certs when ECDH is used. SSL_CTX_set_tmp_ecdh increases reference count, so we have to call EC_KEY_free, otherwise eckey will not be freed. Damn, I was working my way though old patches to port them to Tomcat tcnative and forgot to check the current code. 2) In modules/ssl/ssl_private.h I see /** * The following features all depend on TLS extension support. * Within this block, check again for features (not version numbers). */ #if !defined(OPENSSL_NO_TLSEXT) && defined(SSL_set_tlsext_host_name) #define HAVE_TLSEXT I guess this was (one of) the first TLS extention added to OpenSSL, hence OPENSSL_NO_TLSEXT was probably defined at the same time as SSL_set_tlsext_host_name. This code checks if extensions are not disabled (OPENSSL_NO_TLSEXT), but that's relevent only if they exist in OpenSSL (SSL_set_tlsext_host_name). Should we switch the code to: /** * The following features all depend on TLS extension support. * Within this block, check again for features (not version numbers). */ #if !defined(OPENSSL_NO_TLSEXT) That would be true before OPENSSL_NO_TLSEXT existed... Yup, got it. Thanks a bunch, Rainer
Re: svn commit: r1681297 - in /httpd/httpd/branches/2.2.x: ./ CHANGES STATUS docs/manual/mod/mod_log_config.xml modules/loggers/mod_log_config.c
Am 23.05.2015 um 11:28 schrieb Yann Ylavic: On Sat, May 23, 2015 at 11:23 AM, wrote: Author: ylavic Date: Sat May 23 09:23:13 2015 New Revision: 1681297 URL: http://svn.apache.org/r1681297 Log: Merged r979120 from trunk. [] Modified: httpd/httpd/branches/2.2.x/STATUS [] - * mod_log_config: Allow to choose request start or end time - as time stamp in log (httpd traditionally uses start, many - other components, e.g. Tomcat use end time, so they are kind - of hard to correlate). Also add more format choices for time stamps. - Needed get_request_end_time() was already ported back. - trunk patch: http://svn.apache.org/r979120 (remaining parts) - 2.4.x patch: http://svn.apache.org/r979120 (remaining parts) - 2.2.x patch: http://people.apache.org/~rjung/patches/httpd-2.2.x-mod_log_config-more_time_formats-v2.patch - +1: rjung, wrowe, ylavic - rjung: I had forgotten the docs part. Added in v2 patch. OK to keep Bill's vote? Applied since docs is CTR, right? Yes and thanks! Rainer
Re: Upcoming 2.2.x any chance to include the following fixes/additions
Am 24.05.2015 um 23:08 schrieb olli hauer:
Hi,
is there a chance to get the following revisions merged to 2.2.x
- r1551685, r1652929 (fix IPv4 mapping on FreeBSD)
In ssl_engine_dh.c there are calls to generate dh512 and dh1012,
perhaps it is also an idea to drop dh512 and add dh2048 or higher.
-system("openssl gendh $rand -out dh512.pem 512");
-system("openssl gendh $rand -out dh1024.pem 1024");
+system("openssl gendh $rand -out dh1024.pem 1024");
+system("openssl gendh $rand -out dh2048.pem 2048");
I wonder whether we should instead remove that whole embedded perl
script. An improvement was ported back from 2.4 to 2.2 that means you
can simply include the "openssl dhparam" output in the certificate file.
In addition by default the next 2.2 will also choose a prime length
corresponding to the RSA key length in the certificate. So in most cases
user should be just fine. If admins want to tune, they can by generating
params and appending them to the cert file.
What do you think: is there still a need for this embedded perl script?
PS:
on my local 2.2.x test system 'ab.c' from 2.4.13 build fine, perhaps
this is also a candidate for a next 2.2.x release.
Probably a bit to late for now. We are heading for a release real soon.
But thanks for the heads up.
Regards,
Rainer
Re: Two questions on mod_ssl source code details
Am 22.05.2015 um 18:35 schrieb Yann Ylavic: On Fri, May 22, 2015 at 6:29 PM, Rainer Jung wrote: 1) In other code I see EC_KEY_free(ecdh); after EC_KEY *ecdh = EC_KEY_new_by_curve_name(...) and using ecdh, e.g. in SSL_CTX_set_tmp_ecdh(mctx->ssl_ctx, eckey); Should we add the free? Or is it not needed? Anyone knows why? This was added in r1666363: * mod_ssl: fix small memory leak in ssl_init_server_certs when ECDH is used. SSL_CTX_set_tmp_ecdh increases reference count, so we have to call EC_KEY_free, otherwise eckey will not be freed. Ha! It is in trunk and 2.2, but the backport/changes in 2.4 were incomplete. Exactly the free is missing. Proposed now for 2.4 in STATUS. Regards, Rainer
mod_ssl: Reading dhparams and ecparams not only from the first certificate file
Current mod_ssl code tries to read embedded DH and ECC parameters only
from the first certificate file. Although this is documented
"DH and ECDH parameters, however, are only read from the first
SSLCertificateFile directive, as they are applied independently of the
authentication algorithm type."
I find it questionable. I would find it more natural to embed the params
in the cert files they apply to, so e.g. the DH params in the RSA cert
file and the EC params in the ECDH cert file and also to not require a
special order for the files which at the end we do not check. Since
missing the embedded params goes unnoticed (finding them is only a DEBUG
log line) it is not very user friendly.
Can't we simply try to read DH and ECC params from every certificate
file and stop in each of the two cases when we have found some? That
would tighten the user unfriendlyness to the case of having multiple
inconsistent parameters embedded in different cert files. And even that
could be checked and logged as a warning.
I would suggest to move the param extraction a little above in the
certificate loop and only try to extract and use the params if a
previous extraction for that type did not already succeed. See below for
a patch suggestion. It moved the read code into the cert loop, removes
the NULL check for certfile (it is done in the loop condition), adds a
boolean dhparams_found and ecparams_found to track whether we already
found some and adds warnings if we find them more than once or if found
ecparams are not valid. The final "auto" behavior setting stays after
the loop and is executed if ecparams is still NULL.
Related is handling of keys embedded in cert files. AFAIK we only try to
read the key from the certificate file instead of a configured key file,
if there is no key file for the same index configured. That means if you
start mixing embedded keys and separate key files, all certificates with
separate key files must come first, then the certificates with the
embedded keys (and the order must match).For this I don't have a better
solution than just documenting it.
Regards,
Rainer
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c (revision 1681275)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -1039,8 +1039,10 @@
int i;
X509 *cert;
DH *dhparams;
+int dhparams_found = 0;
#ifdef HAVE_ECC
EC_GROUP *ecparams;
+int ecparams_found = 0;
int nid;
EC_KEY *eckey = NULL;
#endif
@@ -1174,40 +1176,67 @@
SSL_free(ssl);
#endif
+/*
+ * Try to read DH parameters from the SSLCertificateFile
+ */
+dhparams = ssl_dh_GetParamFromFile(certfile);
+if (dhparams) {
+if (dhparams_found) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s,
APLOGNO(02901)
+ "Custom DH parameters already loaded for %s,"
+ " ignored from %s",
+ vhost_id, certfile);
+}
+else {
+SSL_CTX_set_tmp_dh(mctx->ssl_ctx, dhparams);
+dhparams_found = 1;
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(02540)
+ "Custom DH parameters (%d bits) for %s
loaded from %s",
+ BN_num_bits(dhparams->p), vhost_id, certfile);
+}
+}
+
+#ifdef HAVE_ECC
+/*
+ * Try to read the ECDH curve name from SSLCertificateFile
+ */
+ecparams = ssl_ec_GetParamFromFile(certfile);
+if (ecparams) {
+if (ecparams_found) {
+ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s,
APLOGNO(02902)
+ "Custom ECDH parameters already loaded for
%s,"
+ " ignored from %s",
+ vhost_id, certfile);
+}
+else {
+if ((nid = EC_GROUP_get_curve_name(ecparams)) &&
+(eckey = EC_KEY_new_by_curve_name(nid))) {
+SSL_CTX_set_tmp_ecdh(mctx->ssl_ctx, eckey);
+ecparams_found = 1;
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
APLOGNO(02541)
+ "ECDH curve %s for %s specified in %s",
+ OBJ_nid2sn(nid), vhost_id, certfile);
+}
+else {
+ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
APLOGNO(02903)
+ "Invalid ECDH parameters for %s
ignored from %s",
+ vhost_id, certfile);
+}
+}
+}
+#endif
+
ap_log_error(APLOG_MARK, APLOG_INFO, 0, s, APLOGNO(02568)
"Certificate and private key %s configured from
%s and %s",
key_id, certfi
Re: 2.4 release backport list
Hi Stefan, Am 26.05.2015 um 10:37 schrieb Stefan Eissing: Sorry, if this question has an obvious answer which I was unable to find: where would I find a list of the changes that will be backported to the 2.4.13 release in order to see if a change has received enough votes? The backports that are currently on vote are always in the STATUS file which sits in the top level directory of the respective branch in svn. For example: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?view=co If an item has enough votes it is moved in the file from "PATCHES PROPOSED TO BACKPORT FROM TRUNK:" to "PATCHES ACCEPTED TO BACKPORT FROM TRUNK:". Next it gets applied to the code and removed from the file. After the backport you can find the backported items in the CHANGES file in svn (if the backport contains a user facing change). Most backports also are done using "svn merge", so you can also look at the svn:mergeinfo property of the top level directory of the branch. Finally you can diff ... Some parts can be applied without going through status, mostly docs changes and some platform specific things. All changes be it to STATUS, to CHANGES or some other files in svn are mailed to c...@httpd.apache.org to which you could subscribe, if you want to follow more closely. Regards, Rainer
Re: mod_ssl: Reading dhparams and ecparams not only from the first certificate file
Am 26.05.2015 um 11:00 schrieb Tim Bannister: On 26 May 2015, at 09:37, Reindl Harald wrote: Am 26.05.2015 um 10:33 schrieb Rainer Jung: Current mod_ssl code tries to read embedded DH and ECC parameters only from the first certificate file. Although this is documented "DH and ECDH parameters, however, are only read from the first SSLCertificateFile directive, as they are applied independently of the authentication algorithm type." I find it questionable. I would find it more natural to embed the params in the cert files they apply to, so e.g. the DH params in the RSA cert file and the EC params in the ECDH cert file and also to not require a special order for the files which at the end we do not check. Since missing the embedded params goes unnoticed (finding them is only a DEBUG log line) it is not very user friendly honestly it would be much more user friendly to have a own parameter for that which would make it easy to regenerate the params via cronjobs without touching the PEM file containing the real certificate and private key With that kind of directive it would also leave flexibility for this kind of thing: DHParamsEC /tmp/example DHParamsEC none DHParamsEC auto (that last case – I'm imagining that httpd generates the D-H parameters at each startup, blocking use of ECDH until generation is complete). I think the way forward is SSLOpenSSLConfCmd which tries to get rid of one new mod_ssl directive per new OpenSSL feature. But that is 1.0.2 only. So for a transitory phase we need something else and at least me I'm happy, that you can already configure the params (by embedding in the cert file). Regards, Rainer
Re: 2.4 release backport list
Am 26.05.2015 um 11:07 schrieb Yann Ylavic: Oups, several simultaneous responses... That shows how much we like him (his work) :)
Re: mod_ssl: Reading dhparams and ecparams not only from the first certificate file
Am 27.05.2015 um 08:40 schrieb Kaspar Brand: On 26.05.2015 10:33, Rainer Jung wrote: I find it questionable. I would find it more natural to embed the params in the cert files they apply to, so e.g. the DH params in the RSA cert file and the EC params in the ECDH cert file and also to not require a special order for the files which at the end we do not check. Since missing the embedded params goes unnoticed (finding them is only a DEBUG log line) it is not very user friendly. When I added this with r1527295, I didn't expect custom [EC]DH parameters in a certificate file to be the typical case for a mod_ssl configuration - and even in the light of Logjam, I don't think that we would want to recommend creating custom DH parameters for the average admin. As long as 2048-bit RSA keys are configured (the standard for certs issued by publicly-trusted CAs these days), there's nothing wrong with relying on the built-in DH parameters, i.e. those from RFC 3526. [1] Can't we simply try to read DH and ECC params from every certificate file and stop in each of the two cases when we have found some? That would tighten the user unfriendlyness to the case of having multiple inconsistent parameters embedded in different cert files. And even that could be checked and logged as a warning. I don't have strong feelings on this, but am not sure if it's worth adding more code to address this specific case. My guess is that multi-cert virtual host configurations with OpenSSL < 1.0.2 are extremely rare, since they are prone to the one-intermediate-CA-cert-only issue, and with OpenSSL 1.0.2 or later, SSLOpenSSLConfCmd is definitely preferrable. OK As far as your observation "to embed the params in the cert files they apply to" is concerned, I think there might be a misunderstanding here: the [EC]DH parameters are orthogonal to the authentication algorithm - for an RSA key, both are applicable (cf. openssl ciphers -v aRSA+DHE and openssl ciphers -v aRSA+ECDHE). Thanks for the correction. That means if you start mixing embedded keys and separate key files, I would definitely discourage from doing so, and wouldn't bother with adding configuration code to address such cases (would introduce unneeded complexity). Putting the the private key into the SSLCertificateFile has been discouraged since the 2.0 release, actually - see the SSLCertificateKeyFile docs added with r93825. What is probably missing is a more prominent notice in the section on SSLCertificateFile. OK I'll have a look at the docs an see whether I can improve them. [1] The weakdh.org site needs an update on this, as acknowledged by a team member meanwhile, see https://www.ietf.org/mail-archive/web/tls/current/msg16515.html Thanks for your helpful comments! Rainer
Re: httpd and OpenSSL 1.0.2
Am 29.05.2015 um 15:16 schrieb Wang, Andy: You might want to reconsider that unless you really really are sure you know what you're doing. On a linux distro, the system installed openssl is considered a fundamental platform infrastructure library. I.e. many many things rely on it. openssl versions are not backward compatible. So if you don't rebuild all of your distro installed dependencies on openssl, you've likedly just screwed up runtime linking of alot of things. Also, the system installed library and the openssl config makefiles may be using incompatible soname mechanisms, which could explain why you're able to link but not run (i.e. at linktime it may be finding the right library, but at runtime it's not). I didn't follow the whole thread, but about linking versus running: at link time the linker will use the files libssl.so and libcrypto.so (or libssl.a and libcrypto.a). Because all it is given is -lssl and -lcrypto as flags. It will look in those files for an entry named SONAME. On linux you can see that name by issuing objdump -p /path/to/my/libssl.so and objdump -p /path/to/my/libcrypto.so Example output: /path/to/my/libssl.so: file format elf64-x86-64 Program Header: ... Dynamic Section: NEEDED libcrypto.so.1.0.0 NEEDED libdl.so.2 NEEDED libz.so.1 NEEDED libc.so.6 SONAME libssl.so.1.0.0 ... Version References: required from libc.so.6: 0x09691a75 0x00 02 GLIBC_2.2.5 Here you can see the SONAME is libssl.so.1.0.0. This name is added as a dependency into the linked binary. At runtime the runtime linker will look for this file, not for libssl.so. During installation of lobssl.so (resp. libcrypto.so) typically the files get linked using a symlink, so it would make no difference. If you start to overwrite parts of the system installation, the two names might point to different content. About compatibility: OpenSSL 1.0.0 up to OpenSSL 1.0.2 have compatible APIs, that's why the SONAME ends with .1.0.0 in all three cases. It is definitely possible to upgrade, i.e. use a newer version in the 1.0.0 to 1.0.2 range during runtime than was used during compile/link time. The other way round only holds for patch versions with the same first three digits. The SSL_CONF_CTX_* symbols you were originally referring to are only part of 1.0.2. So it seems you compiled against header files from 1.0.2 and likely also loinked against a 1.0.2 libssl.so, but at runtime the libssl.so.1.0.0 that the runtime linker finds is version 1.0.0 or 1.0.1. The runtime linker has a search path that is defined on the system and can be influenced using LD_LIBRARY_PATH. The compile time linker is also influenced by compile "-L" flags. Whether some specific libssl.so (or libssl.so.1.0.0) file contains the symbol or not can be checked using the "nm" command: nm /path/to/my/libssl.so1.0.0 | grep SSL_CONF_CTX Example output here: 000581a0 T SSL_CONF_CTX_clear_flags 00058180 T SSL_CONF_CTX_finish 00058250 T SSL_CONF_CTX_free 000582f0 T SSL_CONF_CTX_new 00058280 T SSL_CONF_CTX_set1_prefix 00058190 T SSL_CONF_CTX_set_flags 000581b0 T SSL_CONF_CTX_set_ssl 00058200 T SSL_CONF_CTX_set_ssl_ctx If the symbols are not contained you will get no hits, if they are only referred in the lib but contained in another depenency lib, you get a "U" marker instead of the "T" (also see the nm man page for more possible cases). HTH Rainer
Re: httpd and OpenSSL 1.0.2
Am 29.05.2015 um 18:30 schrieb William A Rowe Jr: Don't be fooled. OpenSSL 1.0.1 did not break binary compatibility, the lib designation remains .so.1.0.0. Can someone confirm whether this was changed in 1.0.2? As I already wrote it didn't. Rainer
Re: httpd and OpenSSL 1.0.2
Am 29.05.2015 um 18:36 schrieb Wang, Andy: It didn't break api compatibly but it sure did break backwards compatibility. I'm pretty sure if you link against 1.0.2 you can't run with an older 1.0.x library. Which is what appears to happen in Mario's case. That's correct. If the app or lib you compile uses symbols only available in newer versions, then this is true. An example is mod_ssl. The runtime version needs to have the same SONAME and must have at least the same numeric OpenSSL version as the compile version. I'm speculating as to why - being related to improperly replacing a system package management maintained library. I don't get the "why": Why what? Why his runtime version is older than the version used during compile time? For that he would have to track down the files used. I tried to gave hints how to do that. Regards, Rainer
Re: ALPN patch comments
Am 29.04.2015 um 13:05 schrieb Kaspar Brand: I did some formatting cleanup in r1676709 and put a patch for 2.4.x online under https://people.apache.org/~kbrand/mod_ssl-2.4.x-alpn_2015-04-29.diff. This should hopefully make it easier for people to test and review (it's an amalgamation of ten revisions from trunk, see the top of the patch file). Question on that ALPN backport patch and the one in the STATUS file: is it clear that the registration setting up the propose and nego callback function arrays should be per connection? Wouldn't that be more a global or per vhost thing? Just asking because of performance reasons. Regards, Rainer
Re: About PR56925's fix (was: svn commit: r1682872 - /httpd/httpd/branches/2.4.x/STATUS)
Am 01.06.2015 um 13:36 schrieb Yann Ylavic: Hi Rainer, On Mon, Jun 1, 2015 at 1:06 PM, wrote: @@ -232,14 +238,14 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: trunk patch: http://svn.apache.org/r1681694 2.4.x patch: trunk works (modulo CHANGES) +1: ylavic + rjung: Would it makes sense to handle 500/503 for the other proxy +protocols similar? I see error_override at least also in the +AJP and FCGI case. I'll have a look at these, looks consitent to do it there too. + rjung: What about setting the note proxy-error-override in general +if an error override happens so it might get more uses in +the future. Would that make sense? I'm not sure to understand here, what would be a "general" way to set the note? It seems to me that each (proxy) module only can tell whether the error comes from itself or the backend. I meant "set it always if a ProxyErrorOverride happens", not "set it if we need it for the 500/503 check later". Maybe this is (for http) already the case, not sure about possible code paths for ProxyErrorOverride. Rainer
Re: mod_ssl: Reading dhparams and ecparams not only from the first certificate file
Am 27.05.2015 um 09:33 schrieb Rainer Jung: Am 27.05.2015 um 08:40 schrieb Kaspar Brand: On 26.05.2015 10:33, Rainer Jung wrote: I find it questionable. I would find it more natural to embed the params in the cert files they apply to, so e.g. the DH params in the RSA cert file and the EC params in the ECDH cert file and also to not require a special order for the files which at the end we do not check. Since missing the embedded params goes unnoticed (finding them is only a DEBUG log line) it is not very user friendly. When I added this with r1527295, I didn't expect custom [EC]DH parameters in a certificate file to be the typical case for a mod_ssl configuration - and even in the light of Logjam, I don't think that we would want to recommend creating custom DH parameters for the average admin. As long as 2048-bit RSA keys are configured (the standard for certs issued by publicly-trusted CAs these days), there's nothing wrong with relying on the built-in DH parameters, i.e. those from RFC 3526. [1] Can't we simply try to read DH and ECC params from every certificate file and stop in each of the two cases when we have found some? That would tighten the user unfriendlyness to the case of having multiple inconsistent parameters embedded in different cert files. And even that could be checked and logged as a warning. I don't have strong feelings on this, but am not sure if it's worth adding more code to address this specific case. My guess is that multi-cert virtual host configurations with OpenSSL < 1.0.2 are extremely rare, since they are prone to the one-intermediate-CA-cert-only issue, and with OpenSSL 1.0.2 or later, SSLOpenSSLConfCmd is definitely preferrable. OK As far as your observation "to embed the params in the cert files they apply to" is concerned, I think there might be a misunderstanding here: the [EC]DH parameters are orthogonal to the authentication algorithm - for an RSA key, both are applicable (cf. openssl ciphers -v aRSA+DHE and openssl ciphers -v aRSA+ECDHE). Thanks for the correction. That means if you start mixing embedded keys and separate key files, I would definitely discourage from doing so, and wouldn't bother with adding configuration code to address such cases (would introduce unneeded complexity). Putting the the private key into the SSLCertificateFile has been discouraged since the 2.0 release, actually - see the SSLCertificateKeyFile docs added with r93825. What is probably missing is a more prominent notice in the section on SSLCertificateFile. OK I'll have a look at the docs an see whether I can improve them. [1] The weakdh.org site needs an update on this, as acknowledged by a team member meanwhile, see https://www.ietf.org/mail-archive/web/tls/current/msg16515.html I edited the mod_ssl docs and faq in r1682923 and r1682937 (trunk), r1682929 and r1682939 (2.4) and r1682942 (2.2). I hope things are at least as clear as before my editing. Regards, Rainer
Re: [VOTE] Release Apache httpd 2.4.13 as GA
Am 04.06.2015 um 18:33 schrieb Jim Jagielski: The pre-release test tarballs for Apache httpd 2.4.13 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.13 GA. [X] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. +1 to release, thanks for RMing. In short: No regressions found. Detailed report: - Sigs and hashes OK - contents of tarballs identical - contents of tag and tarballs identical except for expected deltas (we could cleanup some m4 files in apr-util/xml/expat/conftools at the end of buildconf, no regression) Built on - Solaris 10 Sparc as 32 Bit Binaries - SLES 10+11 (64 Bits) - RHEL 6 (64 Bits) - FreeBSD 9.1 On FreeBSD 2.4.12 runs on one machine for the ASF. No obvious problems showed up. For all platforms except FreeBSD built - with default (shared) and static modules - with module sets none, few, most, all, reallyall and default (always mod_privileges disabled) - using --enable-load-all-modules - against "included" APR/APU from deps tarball, plus external APR/APU 1.5.2/1.5.4 - using external libraries - expat 2.1.0 - pcre 8.37 - openssl 1.0.1m - lua 5.2.4 - distcache 1.5.1 - libxml2 2.9.2 - Tool chain: - platform gcc except for Solaris (gcc 4.1.2 for Solaris 8 and 4.9.2 for Solaris 10) - CFLAGS: -O2 -g -Wall -fno-strict-aliasing (and -mpcu=v9 on Solaris) All builds succeeded - one compiler warning server/mpm/event/event.c:1438: warning: 'last' may be used uninitialized in this function Tested for - Solaris 10 (32), SLES 10+11 (64), RHEL 6 (64) - MPMs prefork, worker, event - default (shared) and static modules - log levels info, debug and trace8 - module set reallyall (121 modules plus MPMs) The following test failures were seen: a Test 4 or 5 in t/modules/dav.t: Happens for 33 out of 324 runs. Creation, modified and now times not in the correct order. This seems to be a system issue, all tests done on NFS, many tested on virtualized guests. Not a regression. b Various tests in t/apache/expr_string.t: (6, 11, 14, 17, 20 ,23) Happens for 65 out of 324 runs (almost all on SLES 10, 6 on RHEL6 and 2 on Solaris). The failure is always on line 68, where the error_log contents are checked. Not a regression. c Tests 55-57 of t/modules/cgi.t testing contents of ScriptLog. The tests fail for "reallyall" modules. Likely similar than what I observed for 2.4.12. Fix probably by porting r1651085 from mod_cgi to mod_cgid. Not a regression. On FreeBSD I see the following failures: t/apache/limits.t (Wstat: 0 Tests: 12 Failed: 1) Failed test: 8 t/modules/aaa.t (Wstat: 0 Tests: 40 Failed: 3) Failed tests: 23-24, 27 t/ssl/pr12355.t (Wstat: 0 Tests: 10 Failed: 4) Failed tests: 3-4, 7-8 t/ssl/pr43738.t (Wstat: 0 Tests: 4 Failed: 2) Failed tests: 1-2 Since I don't have result from previous releases this is just for information. Regards, Rainer
Re: [VOTE] Release Apache httpd 2.4.13 as GA
Am 08.06.2015 um 03:34 schrieb Jeff Trawick:
On Sun, Jun 7, 2015 at 1:20 PM, Rainer Jung mailto:rainer.j...@kippdata.de>> wrote:
...
On FreeBSD I see the following failures:
t/apache/limits.t (Wstat: 0 Tests: 12 Failed: 1)
Failed test: 8
10.1: limits.t hangs for me after testing 7/12 if I have the kernel
accept filter loaded; passes fine otherwise
(presumably "hang" is just temporary, until the testcase is timed out)
Correct, it hangs for me as well, but just waiting long enough the test
times our and proceeds.
t/modules/aaa.t (Wstat: 0 Tests: 40 Failed: 3)
Failed tests: 23-24, 27
I don't see that with or without accept filter loaded
OK, I analyzed that: my test install failed to install HTTP::Cookies.
That resulted in a failure to reset the UA in t/modules/aaa.t when
switching to form based auth checks. The old UA still had redirect
support active and thus the test failed, because it tested conditions on
the wrong response. The failure to create a new UA was hidden, because
Apache-Test/lib/Apache/TestRequest.pm uses
172 eval { $UA ||= __PACKAGE__->new(%$args); };
and the eval hides the error (likely on purpose for other situations).
t/ssl/pr12355.t (Wstat: 0 Tests: 10 Failed: 4)
Failed tests: 3-4, 7-8
ditto (tested only with accept filter unloaded)
t/ssl/pr43738.t (Wstat: 0 Tests: 4 Failed: 2)
Failed tests: 1-2
ditto (tested only with accept filter unloaded)
The failures have to do with renegotiations on POST. I see
[Mon Jun 08 05:00:10.525918 2015] [ssl:trace4] [pid 41020:tid
34396698624] ssl_engine_io.c(2059): [client 127.0.0.1:57206] OpenSSL:
I/O error, 5 bytes expected to read on BIO#80
2369be0 [mem: 813817003]
[Mon Jun 08 05:00:10.525934 2015] [ssl:debug] [pid 41020:tid
34396698624] ssl_engine_kernel.c(802): [client 127.0.0.1:57206] AH02260:
Performing full renegotiation: complete handshake protocol (client does
support secure renegotiation)
then a reneg handshake but finally:
[Mon Jun 08 05:00:10.527224 2015] [ssl:error] [pid 41020:tid
34396698624] [client 127.0.0.1:57206] AH02261: Re-negotiation handshake
failed
[Mon Jun 08 05:00:10.527250 2015] [ssl:error] [pid 41020:tid
34396698624] SSL Library Error: error:1408A0C1:SSL
routines:SSL3_GET_CLIENT_HELLO:no shared cipher -- Too restrictive
SSLCipherSuite or using DSA server certificate?
The config for the test case wants
SSLCipherSuite RC4-MD5
That it fails is a bit strange, because the https communication in
principle works and the OpenSSL used does support that cipher.
Rainer
Re: svn commit: r1685052 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_config.c
Am 12.06.2015 um 13:49 schrieb Yann Ylavic: Hi Christophe, On Fri, Jun 12, 2015 at 1:26 PM, Christophe JAILLET wrote: should this warning at startup be an issue, why not just remove it in 2.4.x and keep it in trunk? Having the depreciation written in doc (and in migration note for 2.4 -> 2.6/3.0 one day) could be enough, no? Probably, but the (only one) warning per startup can possibly encourage users to look at the doc :) Let's see what others say. I don't have a strong opinion, but if we want to remove the directive in the next version, then it would help to keep the deprecation logging to make people aware and reduce the migration complains a bit. Logging only once instead of for each certificate is IMHO enough and much better. As to if the current situation in 2.4.14 is a problem or should be tolerated (lots of log output for people with huge numbers of certificates) I'm quite undecided. Regards, Rainer
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Am 12.06.2015 um 18:48 schrieb Jeff Trawick: On Fri, Jun 12, 2015 at 12:35 PM, Jacob Perkins mailto:jacob.perk...@cpanel.net>> wrote: +1 to Noels comments. We have a ton of servers running Apache 2.4 with our control panel. Doing this in a point release will cause us to have to change our product instead of doing a regular Apache release. When you have a server with 10k+ SSL vhosts, this can cause massive, unexpected problems. I have a feeling that this will cause massive headaches with all those running Apache 2.4. Thanks to Noel's comments, we have dropped this to one message at a quieter log level for the next 2.4.x release, and we can assist with a tiny patch to any recent 2.4.x. It doesn't make sense for us to hold up a release when that change has been in the last several releases however. (That's a high barrier for making progress.) Make sense? Agreed, I forgot about that, the warning exists since 2.4.9 in March 2014. So from my project member point of view you are totally right. Rainer
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Am 12.06.2015 um 19:12 schrieb William A Rowe Jr: Revision 1678233 - (view) (download) (annotate) - [select for diffs] Modified Thu May 7 16:26:43 2015 UTC (5 weeks, 1 day ago) by jim File length: 57106 byte(s) Diff to previous 1674655 (colored) Merge r1676085 from trunk: consistently output SSLCertificateChainFile deprecation warnings Submitted by: kbrand Reviewed/backported by: jim sent the warnings to the console/main server error log, rather than a specific server error log file. Because this is during config parsing, it that may have previously been a bit bucket. So this could be perceived as a regression although the logic and log file activity was there for some time. Indeed there was a discussion thread for r1562500 in 2014 during which Falco Schwarz reported, that he did *not* get the log message a anywhere (neither console, not log files) when he had the directive only in VirtualHosts. After the 2.4.13 change it seems to be new, that you get the message massively on console, if you have the directive in frequent use inside VHosts. That might well be perceived as a regression. The 2.4.13 change replaced cmd->server in ap_log_error by NULL. The log level "APLOG_WARNING|APLOG_STARTUP" was not changed. Rainer
Re: Apache-Test pre-requisites
Hi Michael, Am 13.06.2015 um 12:10 schrieb Michael Felt: Just a link to the "Howto setup Apache::Test" would be sufficient. The README in the project sends me to mod_perl info, not a list of perl mods needed to be added -- and unfortunately the Apache::Test does not "include" a dependency list either - or CPAN could do this all automatically. Try cpan command install Bundle::ApacheTest to install prerequisites. See also http://search.cpan.org/~shay/Apache-Test-1.39/lib/Bundle/ApacheTest.pm Regards, Rainer On Tue, Jun 9, 2015 at 9:55 PM, Michael Felt mailto:mamf...@gmail.com>> wrote: My apologies for asking - but I am sure there are extra perl mods that need to be installed before Apache-Test will operate as expected. Unfortunately, it does not seem to demand them, and I have forgotten the extra mods I loaded to get 100's of tests compared to the 13 I am getting now. I had hoped CPAN would tell me, but unfortunately, no. cpan> install Apache::Test CPAN: Storable loaded ok Fetching with LWP: ftp://download.xs4all.nl/pub/mirror/CPAN/authors/01mailrc.txt.gz Going to read /var/perl/.cpan/sources/authors/01mailrc.txt.gz Fetching with LWP: ftp://download.xs4all.nl/pub/mirror/CPAN/modules/02packages.details.txt.gz Going to read /var/perl/.cpan/sources/modules/02packages.details.txt.gz Database was generated on Tue, 09 Jun 2015 17:17:02 GMT There's a new CPAN.pm version (v2.10) available! [Current version is v1.7601] You might want to try install Bundle::CPAN reload cpan without quitting the current session. It should be a seamless upgrade while we are running... Fetching with LWP: ftp://download.xs4all.nl/pub/mirror/CPAN/modules/03modlist.data.gz Going to read /var/perl/.cpan/sources/modules/03modlist.data.gz Going to write /var/perl/.cpan/Metadata Apache::Test is up to date. Reminders are welcome! Michael Tests are ending with: Failed 2/13 test scripts, 84.62% okay. 7/43 subtests failed, 83.72% okay. whereas before I was gettign numbers such as: Failed 18/109 test programs. 247/4555 subtests failed. And I have also had all test successful... But do not have those saved. Mainly I am looking at 2/13 and 7/43 compared to 18/109 and 247/4555
Re: Apache-Test pre-requisites
Am 13.06.2015 um 12:23 schrieb Rainer Jung: Hi Michael, Am 13.06.2015 um 12:10 schrieb Michael Felt: Just a link to the "Howto setup Apache::Test" would be sufficient. The README in the project sends me to mod_perl info, not a list of perl mods needed to be added -- and unfortunately the Apache::Test does not "include" a dependency list either - or CPAN could do this all automatically. Try cpan command install Bundle::ApacheTest to install prerequisites. See also http://search.cpan.org/~shay/Apache-Test-1.39/lib/Bundle/ApacheTest.pm There's some more info in the README file you can find after checking out http://svn.apache.org/repos/asf/httpd/test/framework/trunk/ or browsing via http://svn.apache.org/viewvc/httpd/test/framework/trunk/ Regards, Rainer
Re: [VOTE] Release Apache httpd 2.4.14 as GA
2.4.14 as GA Regression: All works fine except a Proxy Pass to Sambar server, was working ok with 2.4.12. ProxyPasses to other servers the Sambar works fine. ProxyPass /sysadmin http://127.0.0.1:81/sysadmin ProxyPassReverse /sysadmin http://127.0.0.1:81/sysadmin Calling with http://127.0.0.1:8080/sysadmin/ gives AH01110: error reading response : [Sat Jun 13 13:23:08.010826 2015] [authz_core:debug] [pid 5684:tid 1128] mod_authz_core.c(834): [client ::1:51072] AH01628: authorization result: granted (no directives) [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128] mod_proxy.c(1157): [client ::1:51072] AH01143: Running scheme http handler (attempt 0) [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128] proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1) [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128] proxy_util.c(2199): [client ::1:51072] AH00944: connecting http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81 <http://127.0.0.1:81> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128] proxy_util.c(2408): [client ::1:51072] AH00947: connected /sysadmin/ to 127.0.0.1:81 <http://127.0.0.1:81> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128] proxy_util.c(2782): AH02824: HTTP: connection established with 127.0.0.1:81 <http://127.0.0.1:81> (127.0.0.1) [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128] proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81 <http://127.0.0.1:81> (127.0.0.1) [Sat Jun 13 13:23:08.010826 2015] [proxy_http:error] [pid 5684:tid 1128] (20014)Internal error (specific information not available): [client ::1:51072] AH01110: error reading response [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128] proxy_util.c(2160): AH00943: HTTP: has released connection for (127.0.0.1) [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128] proxy_util.c(2878): [remote 127.0.0.1:81 <http://127.0.0.1:81>] AH02642: proxy: connection shutdown -Original Message- From: Jim Jagielski Sent: Thursday, June 11, 2015 4:08 PM Newsgroups: gmane.comp.apache.devel To: httpd Subject: [VOTE] Release Apache httpd 2.4.14 as GA The pre-release test tarballs for Apache httpd 2.4.14 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. NOTE: The *-deps are only there for convenience. Thx! -- Born in Roswell... married an alien... http://emptyhammock.com/ -- kippdata informationstechnologie GmbH Tel: 0228 98549 -0 Bornheimer Str. 33aFax: 0228 98549 -50 53111 Bonn www.kippdata.de HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417 Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Am 11.06.2015 um 16:08 schrieb Jim Jagielski: The pre-release test tarballs for Apache httpd 2.4.14 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA. [ ] +1: Good to go [ ] +0: meh [X] -1: Danger Will Robinson. And why. Not an easy call. -1 but even more thanks for RMing. Negative vote due to: - chance of breaking chunked encoding due to spec intolerance. Proxy example reported by Steffen plus at least anecdotal evidence by Jeff (Apache 1.3 backends). - mass occurrence of SSLCertificateChainFile deprecation warning IMHO it would be better to tolerate white space in chunk header, as suggested by Yann now in STATUS. Concerning the deprecation warnings I'm not sure what the current consensus for best behavior is. I think we want only one log message, not one per VHosts. Probably undecided currently: - log level of this one message (IMHO: WARNING) - send it to log file only or also to console (IMHO: log file only) - should we indicate in the message, that here might be other places using SSLCertificateChainFile as well? (IMHO yes) - should we log all the other places, but only to log file and with info or debug log level? (IMHO no, because it could be quite a lot and switching to debug would make it invisible for most people; find/grep is not that hard) Test using test suite: In short: No regressions found. Detailed report: - Sigs and hashes OK - contents of tarballs identical - contents of tag and tarballs identical except for expected deltas (we could cleanup some m4 files in apr-util/xml/expat/conftools at the end of buildconf, no regression) Built on - Solaris 8+10 Sparc as 32 Bit Binaries - SLES 10+11 (64 Bits) - RHEL 6 (64 Bits) For all platforms built - with default (shared), shared and static modules - with module sets none, few, most, all, reallyall and default (always mod_privileges disabled) - using --enable-load-all-modules - against "included" APR/APU from deps tarball, plus external APR/APU 1.5.2/1.5.4 - using external libraries - expat 2.1.0 - pcre 8.37 - openssl 1.0.1n - lua 5.2.4 - distcache 1.5.1 - libxml2 2.9.2 - Tool chain: - platform gcc except for Solaris (gcc 4.1.2 for Solaris 8 and 4.9.2 for Solaris 10) - CFLAGS: -O2 -g -Wall -fno-strict-aliasing (and -mpcu=v9 on Solaris) All builds succeeded - two compiler warnings server/mpm/event/event.c:1438: warning: 'last' may be used uninitialized in this function ssl/ssl_util_stapling.c:657: warning: 'ok' may be used uninitialized in this function Tested for - Solaris 8+10 (32), SLES 10+11 (64), RHEL 6 (64) - MPMs prefork, worker, event (except event on Solaris8, unsupported) - default, shared and static modules - log levels info, debug and trace8 - module set reallyall (121 modules plus MPMs) The following test failures were seen: a Test 4 or 5 in t/modules/dav.t: Happens for 27 out of 364 runs. Creation, modified and now times not in the correct order. This seems to be a system issue, all tests done on NFS, many tested on virtualized guests. Not a regression. b Various tests in t/apache/expr_string.t: (6, 11, 14, 17, 20 ,23) Happens for 63 out of 364 runs (almost all on SLES 10, 6 on RHEL6 and 1 on Solaris 8). The failure is always on line 68, where the error_log contents are checked. Not a regression. c Tests 55-57 of t/modules/cgi.t testing contents of ScriptLog. Likely similar than what I observed for 2.4.12. Fix probably by porting r1651085 from mod_cgi to mod_cgid. Not a regression. Regards, Rainer
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Am 14.06.2015 um 19:17 schrieb Rainer Jung: [X] -1: Danger Will Robinson. And why. Not an easy call. -1 but even more thanks for RMing. Negative vote due to: - chance of breaking chunked encoding due to spec intolerance. s/spec/space/ - Sorry. Proxy example reported by Steffen plus at least anecdotal evidence by Jeff (Apache 1.3 backends). - mass occurrence of SSLCertificateChainFile deprecation warning
