prefork and APR_HAS_THREADS
Some popular Unix distros package two httpd binaries - one built with the prefork MPM and the other built with the worker MPM - but only one set of libraries and modules. I assume the libraries and modules are the ones compiled for the worker mpm. Is the performance impact of the APR_HAS_THREADS code blocks in these libraries/modules small/neglible as opposed to if they had been built for the prefork MPM? Are there any other implications of using libraries/modules built with APR_HAS_THREADS with the prefork MPM? Thanks, Arvind
Re: prefork and APR_HAS_THREADS
Arvind Srinivasan wrote: Some popular Unix distros package two httpd binaries - one built with the prefork MPM and the other built with the worker MPM - but only one set of libraries and modules. I assume the libraries and modules are the ones compiled for the worker mpm. Is the performance impact of the APR_HAS_THREADS code blocks in these libraries/modules small/neglible as opposed to if they had been built for the prefork MPM? Negligible with a few exceptions. PHP is one of them, it becomes quite bulky when you --enable-zts. Yes, a module built for worker will work against prefork MPM, if the prefork MPM has been built against a threaded APR. Bill
Re: prefork and APR_HAS_THREADS
IMHO APR_HAS_THREADS has nothing to do with the choice of your MPM (except BEOS). It only tells you if APR has thread support or not and this only depends on the platform or if you instructed APR explicitly to build without thread support. Regards Rüdiger -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] Gesendet: Dienstag, 28. August 2007 12:37 An: dev@httpd.apache.org Betreff: prefork and APR_HAS_THREADS Some popular Unix distros package two httpd binaries - one built with the prefork MPM and the other built with the worker MPM - but only one set of libraries and modules. I assume the libraries and modules are the ones compiled for the worker mpm. Is the performance impact of the APR_HAS_THREADS code blocks in these libraries/modules small/neglible as opposed to if they had been built for the prefork MPM? Are there any other implications of using libraries/modules built with APR_HAS_THREADS with the prefork MPM? Thanks, Arvind
Re: prefork and APR_HAS_THREADS
William A. Rowe, Jr. wrote: Negligible with a few exceptions. PHP is one of them, it becomes quite bulky when you --enable-zts. Yes, a module built for worker will work against prefork MPM, if the prefork MPM has been built against a threaded APR. Thanks. Arvind
Re: prefork and APR_HAS_THREADS
Plüm wrote: IMHO APR_HAS_THREADS has nothing to do with the choice of your MPM (except BEOS). It only tells you if APR has thread support or not and this only depends on the platform or if you instructed APR explicitly to build without thread support. My mistake. I associated APR_HAS_THREADS with the MPM. Arvind
1.3.39?
Since it's expected that there will be quite a delay in the next release of 1.3, assuming no security patches, I'm seriously considering not releasing 1.3.38 in favor of 1.3.39, which includes a minor patch to be sure, but at least it would be a release that could hold for awhile... It would also be kind of poetic that each release skipped a number :)
Re: [Fwd: svn commit: r570419 - in /httpd/httpd/branches/2.2.x: STATUS modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_util_ssl.h]
done and done On Aug 28, 2007, at 10:08 AM, William A. Rowe, Jr. wrote: Since this changes the user experience, would you mind terribly applying the CHANGES as well? (I format my STATUS entries for CHANGES now, since a diff of CHANGES never applies clean ;-) From: [EMAIL PROTECTED] Date: August 28, 2007 9:40:02 AM EDT To: [EMAIL PROTECTED] Subject: svn commit: r570419 - in /httpd/httpd/branches/2.2.x: STATUS modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_util_ssl.h Reply-To: dev@httpd.apache.org Author: jim Date: Tue Aug 28 06:40:01 2007 New Revision: 570419 URL: http://svn.apache.org/viewvc?rev=570419view=rev Log: Backported Modified: httpd/httpd/branches/2.2.x/STATUS httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_init.c httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_vars.c httpd/httpd/branches/2.2.x/modules/ssl/ssl_util_ssl.h Modified: httpd/httpd/branches/2.2.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS? rev=570419r1=570418r2=570419view=diff == --- httpd/httpd/branches/2.2.x/STATUS (original) +++ httpd/httpd/branches/2.2.x/STATUS Tue Aug 28 06:40:01 2007 @@ -79,16 +79,6 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] -* mod_ssl: Version reporting update; displays 'compiled against' - Apache and build-time SSL Library versions at loglevel [info], - while reporting the run-time SSL Library version in the server - info tags. Helps to identify a mod_ssl built against one flavor - of OpenSSL but running against another (also adds SSL-C version - number reporting.) [William Rowe] -http://svn.apache.org/viewvc?view=revrevision=520701 - Backported to 2.2; -http://people.apache.org/~wrowe/r520701-backport-2.2.patch - +1: wrowe, rpluem, jim PATCHES PROPOSED TO BACKPORT FROM TRUNK: Modified: httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_init.c URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/ modules/ssl/ssl_engine_init.c?rev=570419r1=570418r2=570419view=diff == --- httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_init.c (original) +++ httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_init.c Tue Aug 28 06:40:01 2007 @@ -34,42 +34,21 @@ ** _ */ -static char *ssl_add_version_component(apr_pool_t *p, - server_rec *s, - char *name) -{ -char *val = ssl_var_lookup(p, s, NULL, NULL, name); - -if (val *val) { -ap_add_version_component(p, val); -} - -return val; -} - -static char *version_components[] = { -SSL_VERSION_PRODUCT, -SSL_VERSION_INTERFACE, -SSL_VERSION_LIBRARY, -NULL -}; static void ssl_add_version_components(apr_pool_t *p, server_rec *s) { -char *vals[sizeof(version_components)/sizeof(char *)]; -int i; +char *modver = ssl_var_lookup(p, s, NULL, NULL, SSL_VERSION_INTERFACE); +char *libver = ssl_var_lookup(p, s, NULL, NULL, SSL_VERSION_LIBRARY); +char *incver = ssl_var_lookup(p, s, NULL, NULL, + SSL_VERSION_LIBRARY_INTERFACE); -for (i=0; version_components[i]; i++) { -vals[i] = ssl_add_version_component(p, s, -version_components[i]); -} +ap_add_version_component(p, modver); +ap_add_version_component(p, libver); ap_log_error(APLOG_MARK, APLOG_INFO, 0, s, - Server: %s, Interface: %s, Library: %s, - AP_SERVER_BASEVERSION, - vals[1], /* SSL_VERSION_INTERFACE */ - vals[2]); /* SSL_VERSION_LIBRARY */ + %s compiled against Server: %s, Library: %s, + modver, AP_SERVER_BASEVERSION, incver); } Modified: httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_vars.c URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/ modules/ssl/ssl_engine_vars.c?rev=570419r1=570418r2=570419view=diff == --- httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_vars.c (original) +++ httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_vars.c Tue Aug 28 06:40:01 2007 @@ -635,31 +635,41 @@ static char *ssl_var_lookup_ssl_version(apr_pool_t *p, char *var) { +static char interface[] = mod_ssl/ MOD_SSL_VERSION; +static char library_interface[] = SSL_LIBRARY_TEXT; +static char *library = NULL; char *result; -char *cp, *cp2; - -result = NULL; - -if (strEQ(var, PRODUCT)) { -#if defined(SSL_PRODUCT_NAME) defined(SSL_PRODUCT_VERSION) -result = apr_psprintf(p, %s/%s,
[Fwd: svn commit: r570419 - in /httpd/httpd/branches/2.2.x: STATUS modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_util_ssl.h]
Since this changes the user experience, would you mind terribly applying the CHANGES as well? (I format my STATUS entries for CHANGES now, since a diff of CHANGES never applies clean ;-) ---BeginMessage--- Author: jim Date: Tue Aug 28 06:40:01 2007 New Revision: 570419 URL: http://svn.apache.org/viewvc?rev=570419view=rev Log: Backported Modified: httpd/httpd/branches/2.2.x/STATUS httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_init.c httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_vars.c httpd/httpd/branches/2.2.x/modules/ssl/ssl_util_ssl.h Modified: httpd/httpd/branches/2.2.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=570419r1=570418r2=570419view=diff == --- httpd/httpd/branches/2.2.x/STATUS (original) +++ httpd/httpd/branches/2.2.x/STATUS Tue Aug 28 06:40:01 2007 @@ -79,16 +79,6 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] -* mod_ssl: Version reporting update; displays 'compiled against' - Apache and build-time SSL Library versions at loglevel [info], - while reporting the run-time SSL Library version in the server - info tags. Helps to identify a mod_ssl built against one flavor - of OpenSSL but running against another (also adds SSL-C version - number reporting.) [William Rowe] -http://svn.apache.org/viewvc?view=revrevision=520701 - Backported to 2.2; -http://people.apache.org/~wrowe/r520701-backport-2.2.patch - +1: wrowe, rpluem, jim PATCHES PROPOSED TO BACKPORT FROM TRUNK: Modified: httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_init.c URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_init.c?rev=570419r1=570418r2=570419view=diff == --- httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_init.c (original) +++ httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_init.c Tue Aug 28 06:40:01 2007 @@ -34,42 +34,21 @@ ** _ */ -static char *ssl_add_version_component(apr_pool_t *p, - server_rec *s, - char *name) -{ -char *val = ssl_var_lookup(p, s, NULL, NULL, name); - -if (val *val) { -ap_add_version_component(p, val); -} - -return val; -} - -static char *version_components[] = { -SSL_VERSION_PRODUCT, -SSL_VERSION_INTERFACE, -SSL_VERSION_LIBRARY, -NULL -}; static void ssl_add_version_components(apr_pool_t *p, server_rec *s) { -char *vals[sizeof(version_components)/sizeof(char *)]; -int i; +char *modver = ssl_var_lookup(p, s, NULL, NULL, SSL_VERSION_INTERFACE); +char *libver = ssl_var_lookup(p, s, NULL, NULL, SSL_VERSION_LIBRARY); +char *incver = ssl_var_lookup(p, s, NULL, NULL, + SSL_VERSION_LIBRARY_INTERFACE); -for (i=0; version_components[i]; i++) { -vals[i] = ssl_add_version_component(p, s, -version_components[i]); -} +ap_add_version_component(p, modver); +ap_add_version_component(p, libver); ap_log_error(APLOG_MARK, APLOG_INFO, 0, s, - Server: %s, Interface: %s, Library: %s, - AP_SERVER_BASEVERSION, - vals[1], /* SSL_VERSION_INTERFACE */ - vals[2]); /* SSL_VERSION_LIBRARY */ + %s compiled against Server: %s, Library: %s, + modver, AP_SERVER_BASEVERSION, incver); } Modified: httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_vars.c URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_vars.c?rev=570419r1=570418r2=570419view=diff == --- httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_vars.c (original) +++ httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_vars.c Tue Aug 28 06:40:01 2007 @@ -635,31 +635,41 @@ static char *ssl_var_lookup_ssl_version(apr_pool_t *p, char *var) { +static char interface[] = mod_ssl/ MOD_SSL_VERSION; +static char library_interface[] = SSL_LIBRARY_TEXT; +static char *library = NULL; char *result; -char *cp, *cp2; - -result = NULL; - -if (strEQ(var, PRODUCT)) { -#if defined(SSL_PRODUCT_NAME) defined(SSL_PRODUCT_VERSION) -result = apr_psprintf(p, %s/%s, SSL_PRODUCT_NAME, SSL_PRODUCT_VERSION); -#else -result = NULL; -#endif -} -else if (strEQ(var, INTERFACE)) { -result = apr_psprintf(p, mod_ssl/%s, MOD_SSL_VERSION); -} -else if (strEQ(var, LIBRARY)) { -result = apr_pstrdup(p, SSLeay_version(SSLEAY_VERSION)); -if ((cp = strchr(result, ' ')) != NULL) { + +if
Re: 1.3.39?
-Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Dienstag, 28. August 2007 16:00 An: dev@httpd.apache.org Betreff: 1.3.39? Since it's expected that there will be quite a delay in the next release of 1.3, assuming no security patches, I'm seriously considering not releasing 1.3.38 in favor of 1.3.39, which includes a minor patch to be sure, but at least it would be a release that could hold for awhile... +1. Go Ahead. It would also be kind of poetic that each release skipped a number :) :-) Regards Rüdiger
If-Match / If-None-Match PUT broken-ness in mod_dav
Hello, I am concerned about two particular bugs in mod_dav that have been known for a while. They are bugs 16593 and 38034 and are related to the use of the If-Match and If-None-Match headers when doing PUT requests (and other requests as well such as LOCK). See http://issues.apache.org/bugzilla/show_bug.cgi?id=16593 http://issues.apache.org/bugzilla/show_bug.cgi?id=38034 I consider these bugs serious because If-Match and If-None-Match are the essential headers to use - particularly if the client does not implement locks - to prevent the lost-update problem. Apache's mod_dav is the flagship open-source WebDAV server implementation, but because of these bugs, many clients (such as davfs) do not make use of the If-Match and If-None-Match headers, which IMO should be used on pretty much every PUT request. The first bug, 16593, was opened in 2003. I'm still not up to speed on apache module hacking, but I may be able get one of my team members to submit a patch. The second bug, 38034, was opened in 2005 and has a patch attached as of last month. Is there any way we can get this into trunk, or better yet, the stable branch? Thanks! Tim Olsen
Re: If-Match / If-None-Match PUT broken-ness in mod_dav
On Aug 28, 2007, at 9:08 AM, Tim Olsen wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=16593 http://issues.apache.org/bugzilla/show_bug.cgi?id=38034 I find the mod_dav code a little scary, but on the other hand I have ETags working properly with PUT in mod_atom, and there are a couple of little gotchas that can getcha. So if someone is looking at this, maybe I can help. If nobody's looking at it, I suppose I could hold my breath and wade into the mod_dav swamp, but I'd really rather not, I'd be really worried about breaking something; do we have people here who grok mod_dav could answer questions? I consider these bugs serious because If-Match and If-None-Match are the essential headers to use - particularly if the client does not implement locks - to prevent the lost-update problem. +1 -T
Re: svn commit: r570440 - /httpd/httpd/branches/2.2.x/CHANGES
[EMAIL PROTECTED] wrote: Author: jim Date: Tue Aug 28 07:18:05 2007 New Revision: 570440 URL: http://svn.apache.org/viewvc?rev=570440view=rev Log: document userland change ty kindly!
Re: Decompression with Bucket Brigade
Nick Kew wrote: On Tue, 28 Aug 2007 10:12:47 +0530 prasanna [EMAIL PROTECTED] wrote: I have added filter as below in conf file. AddOutputFilter INFLATE;URLParser;DEFLATE html I take it this is a proxy? (If not, why are the contents coming from the backend ever compressed?) That scenario is exactly what the INFLATE output filter was written for, with parsing modules such as mod_proxy_html and mod_publisher (both of which process links) in the middle. It works, though there are also some recently-fixed bugs, so if you're using something older than 2.2.5 you could usefully upgrade. and also i am using apr_bucket_copy in my module, but whenever i use this i got segmentation fault, is there anything behind this? Sounds like you're using it wrong. Is there any way to solve this problems! See my .sig and/or my existing modules :-) Hi Nick, clicking on the book link gives me: http://service.bfast.com/clients/notify/exmerchant-1.html It looks like a good book, I've just placed an order with amazon. Cheers, Mark -- Mark Harrison Pixar Animation Studios