Re: best way to return the content of a file
Yes. Every virtual host should be able to have a separate configuration,
hence different configs. The server_rec structure points to the virtual
host. There are ways to get the global settings from the global server_rec,
do some searches.on the list archives and you will find that if its what
you needed.
Joe
--
Http://www.silverhawk.net/
On Aug 19, 2012 3:49 AM, nik600 nik...@gmail.com wrote:
On Sat, Aug 18, 2012 at 7:18 PM, nik600 nik...@gmail.com wrote:
On Sat, Aug 18, 2012 at 6:32 PM, Eric Covener cove...@gmail.com wrote:
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.
i've done that, and i've set the configuration per-directory, but it
seems that is have every time the same value, even if called from
different locations:
static const command_reckcache_directives[] =
{
AP_INIT_TAKE1(KcacheEnabled, kcache_set_enabled, NULL,
ACCESS_CONF, KcacheEnabled must have Off or On value),
AP_INIT_TAKE1(KcachePath, kcache_set_path, NULL, ACCESS_CONF,
KcachePath must contain the path),
{ NULL }
};
static void register_hooks(apr_pool_t* pool)
{
/*
* imposto i valori di default
*/
config.enabled=FALSE;
config.path=/var/www;
static const char *succ[] = {mod_proxy.c,mod_alias.c, NULL};
ap_hook_translate_name(kcache_handler, NULL, succ, APR_HOOK_MIDDLE);
}
module AP_MODULE_DECLARE_DATA kcache_module = {
STANDARD20_MODULE_STUFF,
NULL,
NULL,
NULL,
NULL,
kcache_directives,
register_hooks
};
then i have:
in the global config
Directory /
KcacheEnabled Off
/Directory
and in a specific vhost:
Directory /var/www/kcache/trunk/data
KcacheEnabled On
KcachePath /var/www/data
/Directory
finally i've added in my handler:
static int kcache_handler(request_rec* r)
{
apr_status_t s;
ap_log_rerror(APLOG_MARK, APLOG_DEBUG,s,r,KcacheEnabled =
%i,config.enabled);
ap_log_rerror(APLOG_MARK, APLOG_DEBUG,s,r,KcachePath =
%s,config.path);
if(!config.enabled){
ap_log_rerror(APLOG_MARK, APLOG_NOTICE,s,r,KcacheEnabled =
Off,
exiting from kcache);
return DECLINED;
}
...
...
but looking at logs it seems that KcacheEnabled is always On.
Is my approach correct?
Thanks
--
/*/
nik600
http://www.kumbe.it
Ok, i was missing the create_dir_conf and merge_dir_conf handlers.
One more thing (i hope the last :-) ) when the documentation talk
about server configuration handler/merge it is intended by vhost?
Thanks
--
/*/
nik600
http://www.kumbe.it
Re: undesired modules loading
On 19.08.2012 00:20, Roy T. Fielding wrote: 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. The enable-load-all-modules behavior was what the build always did before 2.4. That was a big annoyance and it was decided to no longer load all build modules by default starting with 2.4. So the maintainer mode behaves as for versions before 2.4 w.r.t. loading modules but no longer behaves like the normal mode for 2.4. --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. Modules not working on a platform should not get build, this would be a bug but has not been observed yet. The enable-load-all-modules only means *if* a modules is build, then activate the LoadModule directive in the config. Whether a module is build or not is decided based on the m4 macros that test its dependencies etc. I'd say concerning your original mail, the possible bug is in ssl, i.e. should --without-ssl imply --disable-ssl. I ran three builds on my (Solaris) system with configure flags close to yours, one without maintainer mode, one with it and one with it but --disable-load-all-modules. In all three cases 78 modules get build (including mod_ssl). Without maintainer mode or with maintainer mode but --disable-load-all-modules of these 78 only 21 get loaded by default (no proxy, no ssl): authn_file_module authn_core_module authz_host_module authz_groupfile_module authz_user_module authz_core_module access_compat_module auth_basic_module reqtimeout_module filter_module mime_module log_config_module env_module headers_module setenvif_module version_module unixd_module status_module autoindex_module dir_module alias_module Regards, Rainer
Re: undesired modules loading
On Sunday 19 August 2012, Roy T. Fielding wrote: 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? One reason was to make it easier for httpd developers to run the perl test suite. Otherwise they would always have to enable all modules after a new make install (or not forget some additional configure option).
Re: [VOTE] Release Apache httpd 2.4.3 as GA
On 8/18/2012 8:39 AM, Jim Jagielski wrote: 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 Windows MPM does indeed work rather well. That said, if one has a lot of long running connections that are mostly idle won't one run into exactly the same issues that mod_worker has vs. mod_event? What's the strategy for dealing with large numbers of long-poll requests, long HTTP keepalive settings, etc, with the Windows MPM? Similarly what's the strategy for this on UNIX when /all /the requests in question are HTTPS? Again, we've not hit the limit there with mod_worker, but a major interest in 2.4.x was raising the ceiling in this direction. -- Jess Holle
Re: [VOTE] Release Apache httpd 2.4.3 as GA
+1 on: fed16, OSX 10.8.0, FreeBSD 8.3 On Aug 17, 2012, at 1:34 PM, Jim Jagielski j...@jagunet.com 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: svn commit: r1374640 - /httpd/httpd/branches/2.2.x/STATUS
On 18.8.12 21:51, William A. Rowe Jr. wrote: 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. After a closer look at the mechanics of OPENSSL_NO_SSL2 in OpenSSL, I think there's a misunderstanding of how OpenSSL exposes this compile-time option to applications linking against libssl. OpenSSL itself only defines OPENSSL_NO_SSL2 in the following case (openssl/ssl.h): #if (defined(OPENSSL_NO_RSA) || defined(OPENSSL_NO_MD5)) !defined(OPENSSL_NO_SSL2) #define OPENSSL_NO_SSL2 #endif (ssl.h is not customized by OpenSSL's Configure script, AFAICT you would have to call openssl version -f and look for any flags set at compile time.) I.e., unless mod_ssl is explicitly compiled with -DOPENSSL_NO_SSL2 (set through CPPFLAGS/CFLAGS), an #ifdef OPENSSL_NO_SSL2 has no effect, and the blocks enclosed with #ifndef OPENSSL_NO_SSL2 will get included, irrespective of how OpenSSL has been compiled. 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. I'm not sure what exactly you're referring to - is there new research showing that it's more than a DoS issue (which is what http://www.openssl.org/news/secadv_20120510.txt currently states)? Generally speaking, users of OpenSSL 1.0.1 (and 1.0.1a/1.0.1b) should upgrade their OpenSSL libraries... I would consider it rather awkward to recommend them an upgrade to httpd 2.2.23, only for being able to disable TLS 1.1/1.2. Kaspar
Re: svn commit: r1374640 - /httpd/httpd/branches/2.2.x/STATUS
On 19/08/2012 18:22, Kaspar Brand wrote: On 18.8.12 21:51, William A. Rowe Jr. wrote: 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. After a closer look at the mechanics of OPENSSL_NO_SSL2 in OpenSSL, I think there's a misunderstanding of how OpenSSL exposes this compile-time option to applications linking against libssl. OpenSSL itself only defines OPENSSL_NO_SSL2 in the following case (openssl/ssl.h): #if (defined(OPENSSL_NO_RSA) || defined(OPENSSL_NO_MD5)) !defined(OPENSSL_NO_SSL2) #define OPENSSL_NO_SSL2 #endif (ssl.h is not customized by OpenSSL's Configure script, AFAICT you would have to call openssl version -f and look for any flags set at compile time.) I.e., unless mod_ssl is explicitly compiled with -DOPENSSL_NO_SSL2 (set through CPPFLAGS/CFLAGS), an #ifdef OPENSSL_NO_SSL2 has no effect, and the blocks enclosed with #ifndef OPENSSL_NO_SSL2 will get included, irrespective of how OpenSSL has been compiled. The usual way is to use no-ssl2 as an argument to Configure or config which then adds OPENSSL_NO_SSL2 into crypto/opensslconf.h Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: svn commit: r1374640 - /httpd/httpd/branches/2.2.x/STATUS
On 19.8.12 19:37, Dr Stephen Henson wrote: On 19/08/2012 18:22, Kaspar Brand wrote: (ssl.h is not customized by OpenSSL's Configure script, AFAICT you would have to call openssl version -f and look for any flags set at compile time.) I.e., unless mod_ssl is explicitly compiled with -DOPENSSL_NO_SSL2 (set through CPPFLAGS/CFLAGS), an #ifdef OPENSSL_NO_SSL2 has no effect, and the blocks enclosed with #ifndef OPENSSL_NO_SSL2 will get included, irrespective of how OpenSSL has been compiled. The usual way is to use no-ssl2 as an argument to Configure or config which then adds OPENSSL_NO_SSL2 into crypto/opensslconf.h Ok, thanks for clarifying, I stand corrected. opensslconf.h is included in ssl_private.h via #include openssl/x509_vfy.h, that's why the current 2.2.x code is working as expected. Kaspar
Re: svn commit: r1374640 - /httpd/httpd/branches/2.2.x/STATUS
On 19.8.12 19:59, Kaspar Brand wrote: Ok, thanks for clarifying, I stand corrected. opensslconf.h is included in ssl_private.h via #include openssl/x509_vfy.h, that's why the current 2.2.x code is working as expected. Um, for 2.2.x that should read: in ssl_toolkit_compat.h, and it's actually included through openssl/evp.h (x509_vfy.h is not used in 2.2.x). Kaspar
Re: [VOTE] Release Apache httpd 2.4.3 as GA
+1 on debian 6 and Windows Thanx for the Win SSL Fix Am Sonntag, 19. August 2012 schrieb Jim Jagielski : +1 on: fed16, OSX 10.8.0, FreeBSD 8.3 On Aug 17, 2012, at 1:34 PM, Jim Jagielski j...@jagunet.com 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
On 17.08.2012 19:34, 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. [X] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. +1 Interesting detail: I noticed that when testing with LogLevel trace7 the error logs were much bigger when building against OpenSSL 1.0.0g than when using OpenSSL 1.0.1c plus patch. It seems in some situations with 1.0.0 there's about 64KB data being exchanged and dumped to the error log whereas using 1.0.1 it is less than 100 Bytes. I checked only one occurrence and there it seemed to be related to renegotiations. The protocol spoken was TLSv1 resp. TLSv1.2. I did not find any indication why this should happen in the OpenSSL change log. Test Details: - 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 (32/64 Bits) - SLES 11 (64 Bits) - RHEL 5 and 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 and external APR/APU 1.4.6/1.4.1 - using external libraries - expat 2.1.0 - pcre 8.30 - openssl 1.0.1c (when using bundled APR and openssl 1.0.0g (when using external APR) - lua 5.2.1 - distcache 1.5.1 - libxml2 2.8.0 - Tool chain: - platform gcc except for Solaris (gcc 4.1.2 for Solaris 8 and 4.7.1 for Solaris 10) - CFLAGS: -O2 -g -Wall -fno-strict-aliasing (and -mpcu=v9 on Solaris) All builds succeeded except for - SLES 10 32 and 64 Bits many static builds stop with error or crash during linking httpd. IMHO because of too many commandline params. Not a regression. - only with reallyall, all or most modules - SLES 11 one build stopped in libtool with a Memory error when linking mod_proxy_html. It proceeded correctly when calling make install afterwards. So it seems to be an OS / shell / ressource problem. - only with shared all modules and bundled apr I then updated the installed ksh from 93r to 93s and all builds could be completed. All builds against bundled APR did not detect crypto support, so were build without mod_session_crypto. That's a known problem in apr-util configure and not a regression. My build script workaround was broken this time. Tested for - Solaris 8+10 (32), SLES 10 (32/64), SLES 11 (64), RHEL 5+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 (~117 modules) All Tests passed with the following exceptions: a Test 5 in t/modules/dav.t: 8 out of 240 runs had the created time after the modified time. This seems to be a platform issue, all tests done on NFS, many tested on virtualized guests. Not a regression. b Test 8 in t/ssl/pr12355.t: Of the 240 runs there were two that failed this test, (on RHEL 5). 6 bytes were posted, but only 40934 bytes received Not reproducible, very rare. PR 12355 is: POST incompatible w/ renegotiate https: connection Not a regression. c Test 162 in t/ssl/proxy.t: Of the 240 runs there was one that failed this test, (on RHEL 5). 6 bytes were posted, but only 40934 bytes received Not reproducible, very rare. PR 12355 is: POST incompatible w/ renegotiate https: connection d On Solaris 8 one test run aborted, because at some point the web server could no longer acquire locks. So the children all died and finally the parent process exited. The testing file system was on NFS and multiple servers were tested in parallel, so this is possible. When rerunning the tests they suceeded. Regards, Rainer
