Re: best way to return the content of a file
i'm enabling my module with a Location directive: Location /data SetHandler kcache /Location and i want to control the execution of the module with an initial check: if (!r-handler || strcmp(r-handler, kcache)) return (DECLINED); but r-handler is null if the hook is called in ap_hook_translate_name state, so how can i check this condition? You can't check that condition early. You should implement a directive to enable your module in these early phases.
Re: svn commit: r1374214 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_init.c
On 17.8.12 13:59, jor...@apache.org wrote: Author: jorton Date: Fri Aug 17 11:59:45 2012 New Revision: 1374214 URL: http://svn.apache.org/viewvc?rev=1374214view=rev Log: * modules/ssl/ssl_engine_init.c (ssl_init_proxy_certs): Fix test for missing decrypted private keys, and ensure that the keypair matches. [...] @@ -1412,6 +1421,8 @@ static void ssl_init_proxy_certs(server_ ssl_die(s); } +/* ### Why is all the following done? Why is it necessary or + * useful for the server to try to verify its own client cert? */ It's the somewhat surprising way to let OpenSSL build the chain of the client cert, cf. http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3c4e620c5e.3050...@opensslfoundation.com%3E http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3c4e61c3ce.4020...@velox.ch%3E http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3c4e625521.3000...@opensslfoundation.com%3E Kaspar
Re: svn commit: r1374214 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_init.c
On 18/08/2012 08:00, Kaspar Brand wrote: On 17.8.12 13:59, jor...@apache.org wrote: Author: jorton Date: Fri Aug 17 11:59:45 2012 New Revision: 1374214 URL: http://svn.apache.org/viewvc?rev=1374214view=rev Log: * modules/ssl/ssl_engine_init.c (ssl_init_proxy_certs): Fix test for missing decrypted private keys, and ensure that the keypair matches. [...] @@ -1412,6 +1421,8 @@ static void ssl_init_proxy_certs(server_ ssl_die(s); } +/* ### Why is all the following done? Why is it necessary or + * useful for the server to try to verify its own client cert? */ It's the somewhat surprising way to let OpenSSL build the chain of the client cert, cf. http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3c4e620c5e.3050...@opensslfoundation.com%3E http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3c4e61c3ce.4020...@velox.ch%3E http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3c4e625521.3000...@opensslfoundation.com%3E Though this quirk has been addressed in the current development version of OpenSSL. It's now possible to set certificate chains on a per-type and per-SSL context basis, instead of one per parent SSL_CTX. The functionality is likely to be back ported to OpenSSL 1.0.2. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [VOTE] Release Apache httpd 2.4.3 as GA
On Aug 17, 2012, at 11:01 PM, Jess Holle je...@ptc.com wrote: Downstream customers in my case means customers that will deploy Apache and our products on their own servers. In a great many cases these servers run Windows. Ahh. That explains it. The Windows MPM is designed to be the most optimal implementation for Windows servers, dedicated and specific to Windows. What is it about the Windows MPM which is inadequate to your or your client's needs? We have direct access to Microsoft engineers, so I think they would also be curious as well. MS is quite interested in ensuring Apache httpd runs extremely well on Windows. The clients in most cases are Windows too, but that's a different matter entirely. On 8/17/2012 3:12 PM, Jim Jagielski wrote: I am curious how the number of downstream customers being Windows effects anything on the server side... On Aug 17, 2012, at 2:16 PM, Jess Holle je...@ptc.com wrote: The fact that there is no event MPM equivalent for Windows is a huge gap for 2.4.x. Given the large percentage of our downstream customers using Windows there's not a huge motivation to move to 2.4.x. Moreover, it's my understanding that the event MPM falls back to behaving like the worker MPM in SSL cases. Is that true? If so, then that further decreases the motivation to move to 2.4.x. Overall, given that a large portion of our downstream usages are on Windows, say 50% for the sake of argument, and that a large percentage of our usages are HTTPS, again say 50% for the sake of argument, the benefits of the event MPM are really quite narrow in practice in our case. That said, I didn't know or had forgotten that SSL didn't work with the Windows MPM in 2.4.x. That would be a substantial regression from 2.2.x -- and resolving this would clear the way for 2.4.x being GA barring any other such regressions. -- Jess Holle On 8/17/2012 12:48 PM, Jim Jagielski wrote: In the Announcement you'll see: NOTE to Windows users: The issues with AcceptFilter None replacing Win32DisableAcceptEx appears to have resolved starting with version 2.4.3 make Apache httpd 2.4.x suitable for Windows servers. NOTE: The event MPM is a *nix mpm and has never worked on Windows. On Aug 17, 2012, at 1:38 PM, Jess Holle je...@ptc.com wrote: Does the event MPM now: • Work on Windows? • Work with HTTPS? When both are true 2.4.x will become very interesting. Until then, not so much over 2.2.x. On 8/17/2012 12:34 PM, Jim Jagielski wrote: The pre-release test tarballs for Apache httpd 2.4.3 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.3 GA. NOTE: The -deps tarballs are included here *only* to make life easier for the tester. They will not be, and are not, part of the official release. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. .
Re: [VOTE] Release Apache httpd 2.4.3 as GA
All goes fine on Windows, good to go. Steffen -Original Message- From: Jim Jagielski Sent: Friday, August 17, 2012 7:34 PM Newsgroups: gmane.comp.apache.devel To: dev@httpd.apache.org Subject: [VOTE] Release Apache httpd 2.4.3 as GA The pre-release test tarballs for Apache httpd 2.4.3 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.3 GA. NOTE: The -deps tarballs are included here *only* to make life easier for the tester. They will not be, and are not, part of the official release. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs.
Re: [VOTE] Release Apache httpd 2.4.3 as GA
I'm calling a VOTE on releasing these as Apache httpd 2.4.3 GA. +1 (AIX/PPC64 no regressions)
Re: [VOTE] Release Apache httpd 2.4.3 as GA
On 08/17/2012 07:34 PM, Jim Jagielski wrote: The pre-release test tarballs for Apache httpd 2.4.3 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.3 GA. NOTE: The -deps tarballs are included here *only* to make life easier for the tester. They will not be, and are not, part of the official release. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. [X] +1: Good to go Tested on Debian 6.0, Ubuntu 12.04 and FreeBSD 9.0 (all AMD64) Configured, compiled and installed without problems with all modules built. All (working) tests in the test framework went fine. A few of them may need to have their design checked, as they were run when they shouldn't have been, but this isn't related to 2.4.3, so that's for another day. With regards, Daniel.
Re: svn commit: r1374640 - /httpd/httpd/branches/2.2.x/STATUS
On 8/18/2012 2:32 PM, wr...@apache.org wrote: --- httpd/httpd/branches/2.2.x/STATUS (original) +++ httpd/httpd/branches/2.2.x/STATUS Sat Aug 18 19:32:38 2012 @@ -145,7 +145,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: http://svn.apache.org/viewvc?view=revisionrevision=1225476 http://svn.apache.org/viewvc?view=revisionrevision=1225792 Backport version for 2.2.x of the patches above: - http://people.apache.org/~wrowe/tls11-12-patch-2.2-kbrand-wrowe.1.patch + http://people.apache.org/~wrowe/tls11-12-patch-2.2-kbrand-wrowe.2.patch +1: wrowe, kbrand: The #define HAVE_TLSV1_X stuff should go to ssl_toolkit_compat.h, [wrowe] disagree, since that API was deprecated @@ -160,6 +160,15 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: to drop the #ifndef around SSL_PROTOCOL_SSLV2 in ssl_private.h, this should also make some of the other #if[n]def OPENSSL_NO_SSL2 encapsulations unnecessary. + [wrowe] agreed the patch was wrong, the #ifdef needed to be moved + up four lines. Behavior is now correct in patch .2 + Disagree about retaining SSL_PROTOCOL_SSLV2; this is one + of the most basic design patterns which exists to ensure + that we don't have some lingering code which is still + attempting to pursue SSLV2 games, not to mention that + the various macros and functions in those blocks may + simply disappear disappear in an OPENSSL_NO_SSL2 build. + Bad idea, it helps us catch current and future problems. Thanks for the feedback, Kaspar. Other than shifting the one #ifdef case to the correct line of code, I believe the patch is complete, I've tried to state my case for no further changes. If you would like to propose further changes, I'd really prefer we defer these to 2.2.24-dev so we can TR already. I'm pretty sure you already agree with me that the flexibility to disable a particular cipher in light of exploit research in the very fresh openssl code base makes this patch pretty critical to release for legacy, as well as stable. Even if you can give the patch your +1, we still need one more individual to chime in before we can finish this backport, and as I mention, OpenSSL's CVE-2012-2333 suggests that this patch is a showstopper. Can one more person take a pass through the code, since Stefan didn't have a chance to re-review this week?
Re: [VOTE] Release Apache httpd 2.4.3 as GA
signatures are good source files checked against svn license and notices in place compiles and runs on Mac OS X 10.7.4 +1 Roy
undesired modules loading
I built 2.4.3 with the options ./configure \ --prefix=$tdir \ --with-apr=$adir \ --with-apr-util=$adir \ --without-ssl \ --without-crypto \ --disable-cache \ --without-distcache \ --enable-maintainer-mode but then noticed in the error_log some garbage about [Sat Aug 18 12:26:23.182875 2012] [ssl:warn] [pid 82399:tid 140735220779360] AH01873: Init: Session Cache is not configured [hint: SSLSessionCache] [Sat Aug 18 12:26:23.183039 2012] [lbmethod_heartbeat:notice] [pid 82399:tid 140735220779360] AH02282: No slotmem from mod_heartmonitor which is undoubtedly because several modules are being built and loaded that depend on certain options but do not get disabled by the lack of those options in configure. IMO, none of the following modules should be configured by default: LoadModule file_cache_module modules/mod_file_cache.so LoadModule dumpio_module modules/mod_dumpio.so LoadModule firehose_module modules/mod_firehose.so LoadModule buffer_module modules/mod_buffer.so LoadModule unique_id_module modules/mod_unique_id.so LoadModule remoteip_module modules/mod_remoteip.so LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule proxy_ftp_module modules/mod_proxy_ftp.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so LoadModule proxy_scgi_module modules/mod_proxy_scgi.so LoadModule proxy_ajp_module modules/mod_proxy_ajp.so LoadModule proxy_balancer_module modules/mod_proxy_balancer.so LoadModule proxy_express_module modules/mod_proxy_express.so LoadModule session_module modules/mod_session.so LoadModule session_cookie_module modules/mod_session_cookie.so LoadModule session_dbd_module modules/mod_session_dbd.so LoadModule slotmem_shm_module modules/mod_slotmem_shm.so LoadModule ssl_module modules/mod_ssl.so LoadModule lbmethod_byrequests_module modules/mod_lbmethod_byrequests.so LoadModule lbmethod_bytraffic_module modules/mod_lbmethod_bytraffic.so LoadModule lbmethod_bybusyness_module modules/mod_lbmethod_bybusyness.so LoadModule lbmethod_heartbeat_module modules/mod_lbmethod_heartbeat.so LoadModule dav_fs_module modules/mod_dav_fs.so The vast majority of installations do not want a f*(^ing proxy. Building them is fine -- these should be commented out in the installed httpd.conf unless --with-proxy is enabled. At the very least, modules dependent on SSL must not be loaded if --without-ssl is the configure option. I don't consider this a showstopper for 2.4.3, but I do think they are bugs in trunk and 2.4.x. Roy
Re: undesired modules loading
Hi Roy, On 18.08.2012 22:07, Roy T. Fielding wrote: I built 2.4.3 with the options ./configure \ --prefix=$tdir \ --with-apr=$adir \ --with-apr-util=$adir \ --without-ssl \ --without-crypto \ --disable-cache \ --without-distcache \ --enable-maintainer-mode see below but then noticed in the error_log some garbage about [Sat Aug 18 12:26:23.182875 2012] [ssl:warn] [pid 82399:tid 140735220779360] AH01873: Init: Session Cache is not configured [hint: SSLSessionCache] [Sat Aug 18 12:26:23.183039 2012] [lbmethod_heartbeat:notice] [pid 82399:tid 140735220779360] AH02282: No slotmem from mod_heartmonitor which is undoubtedly because several modules are being built and loaded that depend on certain options but do not get disabled by the lack of those options in configure. IMO, none of the following modules should be configured by default: LoadModule file_cache_module modules/mod_file_cache.so ... LoadModule dav_fs_module modules/mod_dav_fs.so The vast majority of installations do not want a f*(^ing proxy. Building them is fine -- these should be commented out in the installed httpd.conf unless --with-proxy is enabled. Yes, before 2.4.0 we introduced exactly this difference. All modules that were build get a LoadModule line in the installed config, but most are commented out. I don't have the list of modles active by default at hand though. At the very least, modules dependent on SSL must not be loaded if --without-ssl is the configure option. I don't consider this a showstopper for 2.4.3, but I do think they are bugs in trunk and 2.4.x. Partial answer: the current semantics of maintainer-mode is (per configure help): Turn on debugging and compile time warnings and load all compiled modules In fact configure should output Maintainer mode setting LOAD_ALL_MODULES to yes It seems you can switch of this side effect of maintainer mode by explicitly adding --enable-load-all-modules=no to your configure flags. This is the default except for when building in maintainer mode. Regards, Rainer
Re: undesired modules loading
It's '--enable-maintainer-mode' which introduces this behavior. When being built for mere mortals, we are much nicer as far as which modules are built and loaded by default Maybe --enable-maintainer-mode should be renamed --enable-developer-mode On Aug 18, 2012, at 4:07 PM, Roy T. Fielding field...@gbiv.com wrote: I built 2.4.3 with the options ./configure \ --prefix=$tdir \ --with-apr=$adir \ --with-apr-util=$adir \ --without-ssl \ --without-crypto \ --disable-cache \ --without-distcache \ --enable-maintainer-mode but then noticed in the error_log some garbage about [Sat Aug 18 12:26:23.182875 2012] [ssl:warn] [pid 82399:tid 140735220779360] AH01873: Init: Session Cache is not configured [hint: SSLSessionCache] [Sat Aug 18 12:26:23.183039 2012] [lbmethod_heartbeat:notice] [pid 82399:tid 140735220779360] AH02282: No slotmem from mod_heartmonitor which is undoubtedly because several modules are being built and loaded that depend on certain options but do not get disabled by the lack of those options in configure. IMO, none of the following modules should be configured by default: LoadModule file_cache_module modules/mod_file_cache.so LoadModule dumpio_module modules/mod_dumpio.so LoadModule firehose_module modules/mod_firehose.so LoadModule buffer_module modules/mod_buffer.so LoadModule unique_id_module modules/mod_unique_id.so LoadModule remoteip_module modules/mod_remoteip.so LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule proxy_ftp_module modules/mod_proxy_ftp.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so LoadModule proxy_scgi_module modules/mod_proxy_scgi.so LoadModule proxy_ajp_module modules/mod_proxy_ajp.so LoadModule proxy_balancer_module modules/mod_proxy_balancer.so LoadModule proxy_express_module modules/mod_proxy_express.so LoadModule session_module modules/mod_session.so LoadModule session_cookie_module modules/mod_session_cookie.so LoadModule session_dbd_module modules/mod_session_dbd.so LoadModule slotmem_shm_module modules/mod_slotmem_shm.so LoadModule ssl_module modules/mod_ssl.so LoadModule lbmethod_byrequests_module modules/mod_lbmethod_byrequests.so LoadModule lbmethod_bytraffic_module modules/mod_lbmethod_bytraffic.so LoadModule lbmethod_bybusyness_module modules/mod_lbmethod_bybusyness.so LoadModule lbmethod_heartbeat_module modules/mod_lbmethod_heartbeat.so LoadModule dav_fs_module modules/mod_dav_fs.so The vast majority of installations do not want a f*(^ing proxy. Building them is fine -- these should be commented out in the installed httpd.conf unless --with-proxy is enabled. At the very least, modules dependent on SSL must not be loaded if --without-ssl is the configure option. I don't consider this a showstopper for 2.4.3, but I do think they are bugs in trunk and 2.4.x. Roy
Re: undesired modules loading
On Aug 18, 2012, at 1:45 PM, Rainer Jung wrote: Yes, before 2.4.0 we introduced exactly this difference. All modules that were build get a LoadModule line in the installed config, but most are commented out. I don't have the list of modles active by default at hand though. Ah, okay. At the very least, modules dependent on SSL must not be loaded if --without-ssl is the configure option. I don't consider this a showstopper for 2.4.3, but I do think they are bugs in trunk and 2.4.x. Partial answer: the current semantics of maintainer-mode is (per configure help): Turn on debugging and compile time warnings and load all compiled modules Umm, WTF? Why? In fact configure should output Maintainer mode setting LOAD_ALL_MODULES to yes It seems you can switch of this side effect of maintainer mode by explicitly adding --enable-load-all-modules=no to your configure flags. This is the default except for when building in maintainer mode. So, basically what you are saying is that an incompatible change was made to the existing configuration flags so that my build scripts are now broken for no good reason. --enable-load-all-modules Load all modules --enable-maintainer-mode Turn on debugging and compile time warnings and load all compiled modules --enable-debugger-mode Turn on debugging and compile time warnings and turn off optimization --enable-modules=MODULE-LIST Space-separated list of modules to enable | all | most | few | none | reallyall Many of our modules are not cross-platform, yet we expect all of our developers to test with --enable-maintainer-mode. That smells like a brain fart to me. Roy
Re: [VOTE] Release Apache httpd 2.4.3 as GA
On Fri, 2012-08-17 at 13:34 -0400, Jim Jagielski wrote: [X] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. Good to go on Slackware 13.1 13.37(and 14.0 rc2) signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache httpd 2.4.3 as GA
On 8/17/2012 10:34 AM, Jim Jagielski wrote: [X] +1: Good to go Looks good on Windows, the AcceptFilter none+ssl is working very well (thanks Jeff). Gregg
