Re: [jira] Commented: (MODPYTHON-98) wrong handler supplied to req.add_handler() generates error
Graham Dumpleton wrote: On 12/01/2006, at 11:10 AM, Jim Gallacher wrote: Jim Gallacher (JIRA) wrote: [ http://issues.apache.org/jira/browse/MODPYTHON-98? page=comments#action_12362399 ] Jim Gallacher commented on MODPYTHON-98: Applied Graham's suggestions so all these related issues can be considered fixed. Still need to write some unit tests before this issue is marked as resolved. Graham, I've committed the following unit tests for MODPYTHON-98: test_req_add_bad_handler test_req_add_empty_handler_string test_accesshandler_add_handler_to_empty_hl Can you take a look and let me know if you think these properly cover the issue? If they look ok I'll roll the 3.2.6 beta. I get a failure on test_req_add_empty_handler_string. I don't know if this is because of other local hacks I have in place or not. But for it to pass I need the following change to the test.py: This test was of some concern, as I thought the error log message might be inconsistent. Index: test.py === --- test.py (revision 368329) +++ test.py (working copy) @@ -516,8 +516,8 @@ f = open(os.path.join(SERVER_ROOT, logs/error_log)) log = f.read() f.close() -if log.find(contains no 'handler') == -1: -self.fail(Could not find contains no 'handler' in error_log) +if log.find(No module named) == -1: +self.fail(Could not find No module named in error_log) def test_accesshandler_add_handler_to_empty_hl_conf(self): # Note that there is no PythonHandler specified in the the VirtualHost The messages in the error log being: [Thu Jan 12 21:39:35 2006] [notice] mod_python: (Re)importing module '' [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : Traceback (most recent call last): [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/mod_python/apache.py, line 284, in HandlerDispatch\nlog=debug) [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/mod_python/apache.py, line 468, in import_module\nf, p, d = imp.find_module(parts[i], path) [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : ImportError: No module named Your error message actually makes more sense, as the last line in my error_log for this exception mentions PIL. I have *no* idea where that comes from but was hoping that the final line would at least always contain the string contains no 'handler'. Here is my error_log: [Thu Jan 12 08:25:13 2006] [error] [client 127.0.0.1] req_add_empty_handler_string [Thu Jan 12 08:25:13 2006] [notice] mod_python: (Re)importing module '' [Thu Jan 12 08:25:13 2006] [error] [client 127.0.0.1] PythonHandler : Traceback (most recent call last): [Thu Jan 12 08:25:13 2006] [error] [client 127.0.0.1] PythonHandler : File /usr/lib/python2.3/site-packages/mod_python/apache.py, line 291, in HandlerDispatch\narg=req, silent=hlist.silent) [Thu Jan 12 08:25:13 2006] [error] [client 127.0.0.1] PythonHandler : File /usr/lib/python2.3/site-packages/mod_python/apache.py, line 531, in resolve_object\nraise AttributeError, s [Thu Jan 12 08:25:13 2006] [error] [client 127.0.0.1] PythonHandler : AttributeError: module '/usr/lib/python2.3/site-packages/PIL/__init__.pyc' contains no 'handler' Perhaps some other people could check out trunk, run the tests and let me know what shows up in the error_log after the req_add_empty_hander_string line. Thanks, Jim
Re: [jira] Commented: (MODPYTHON-98) wrong handler supplied to req.add_handler() generates error
Ok, this is weird. I've run the tests on a couple of my qemu images and I get the same output as Nicolas and Graham in the error log, but a different output for my development machine. I think I'll rewrite the test to just check the response from the request rather than rooting around in the error_log. The point of the test is to make sure that an exception is raised when req.add_handler(PythonHandler, ) is attempted, so there a couple of different ways to go. I'll make the change and then roll the new beta tarball. Jim Nicolas Lehuen wrote: Hi all, I'm back after a few days without Internet access... I also have the same test failure as Graham. Here is my error log : [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] req_add_empty_handler_string [Thu Jan 12 20:11:24 2006] [notice] mod_python: (Re)importing module '' [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : Traceback (most recent call last): [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : File E:\\Python24\\Lib\\site-packages\\mod_python\\apache.py, line 287, in HandlerDispatch\nlog=debug) [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : File E:\\Python24\\Lib\\site-packages\\mod_python\\apache.py, line 461, in import_module\nf, p, d = imp.find_module(parts[i], path) [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : ImportError: No module named [Thu Jan 12 20:11:25 2006] [notice] mod_python: (Re)importing module 'tests' [Thu Jan 12 20:11:25 2006] [error] [client 127.0.0.1] accesshandler_add_handler_to_empty_hl Regards, Nicolas 2006/1/12, Jim Gallacher [EMAIL PROTECTED]: Graham Dumpleton wrote: On 12/01/2006, at 11:10 AM, Jim Gallacher wrote: Jim Gallacher (JIRA) wrote: [ http://issues.apache.org/jira/browse/MODPYTHON-98? page=comments#action_12362399 ] Jim Gallacher commented on MODPYTHON-98: Applied Graham's suggestions so all these related issues can be considered fixed. Still need to write some unit tests before this issue is marked as resolved. Graham, I've committed the following unit tests for MODPYTHON-98: test_req_add_bad_handler test_req_add_empty_handler_string test_accesshandler_add_handler_to_empty_hl Can you take a look and let me know if you think these properly cover the issue? If they look ok I'll roll the 3.2.6 beta. I get a failure on test_req_add_empty_handler_string. I don't know if this is because of other local hacks I have in place or not. But for it to pass I need the following change to the test.py: This test was of some concern, as I thought the error log message might be inconsistent. Index: test.py === --- test.py (revision 368329) +++ test.py (working copy) @@ -516,8 +516,8 @@ f = open(os.path.join(SERVER_ROOT, logs/error_log)) log = f.read() f.close() -if log.find(contains no 'handler') == -1: -self.fail(Could not find contains no 'handler' in error_log) +if log.find(No module named) == -1: +self.fail(Could not find No module named in error_log) def test_accesshandler_add_handler_to_empty_hl_conf(self): # Note that there is no PythonHandler specified in the the VirtualHost The messages in the error log being: [Thu Jan 12 21:39:35 2006] [notice] mod_python: (Re)importing module '' [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : Traceback (most recent call last): [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/mod_python/apache.py, line 284, in HandlerDispatch\nlog=debug) [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/mod_python/apache.py, line 468, in import_module\nf, p, d = imp.find_module(parts[i], path) [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : ImportError: No module named Your error message actually makes more sense, as the last line in my error_log for this exception mentions PIL. I have *no* idea where that comes from but was hoping that the final line would at least always contain the string contains no 'handler'. Here is my error_log: [Thu Jan 12 08:25:13 2006] [error] [client 127.0.0.1] req_add_empty_handler_string [Thu Jan 12 08:25:13 2006] [notice] mod_python: (Re)importing module '' [Thu Jan 12 08:25:13 2006] [error] [client 127.0.0.1] PythonHandler : Traceback (most recent call last): [Thu Jan 12 08:25:13 2006] [error] [client 127.0.0.1] PythonHandler : File /usr/lib/python2.3/site-packages/mod_python/apache.py, line 291, in HandlerDispatch\narg=req, silent=hlist.silent) [Thu Jan 12 08:25:13 2006] [error] [client 127.0.0.1] PythonHandler : File
Re: [jira] Commented: (MODPYTHON-98) wrong handler supplied to req.add_handler()generates error
FWIW, I use Python 2.3 on Mac OS X. Nicolas is probably using Win32 as usual. I mention this as I wouldn't be surprised if different versions of Python on different platforms behaved differently when given strange module names for importing. Take as an example prior case where someone was using a/b for a module name. Ie., directory name, slash, and then module name. This wouldn't work on Mac OS X but did work on Linux. Result was that it allowed loading of a module in a subdirectory without need for use of packages. Not sure what Win32 did. Graham Jim Gallacher wrote .. Ok, this is weird. I've run the tests on a couple of my qemu images and I get the same output as Nicolas and Graham in the error log, but a different output for my development machine. I think I'll rewrite the test to just check the response from the request rather than rooting around in the error_log. The point of the test is to make sure that an exception is raised when req.add_handler(PythonHandler, ) is attempted, so there a couple of different ways to go. I'll make the change and then roll the new beta tarball. Jim Nicolas Lehuen wrote: Hi all, I'm back after a few days without Internet access... I also have the same test failure as Graham. Here is my error log : [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] req_add_empty_handler_string [Thu Jan 12 20:11:24 2006] [notice] mod_python: (Re)importing module '' [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : Traceback (most recent call last): [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : File E:\\Python24\\Lib\\site-packages\\mod_python\\apache.py, line 287, in HandlerDispatch\nlog=debug) [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : File E:\\Python24\\Lib\\site-packages\\mod_python\\apache.py, line 461, in import_module\nf, p, d = imp.find_module(parts[i], path) [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : ImportError: No module named [Thu Jan 12 20:11:25 2006] [notice] mod_python: (Re)importing module 'tests' [Thu Jan 12 20:11:25 2006] [error] [client 127.0.0.1] accesshandler_add_handler_to_empty_hl Regards, Nicolas 2006/1/12, Jim Gallacher [EMAIL PROTECTED]: Graham Dumpleton wrote: On 12/01/2006, at 11:10 AM, Jim Gallacher wrote: Jim Gallacher (JIRA) wrote: [ http://issues.apache.org/jira/browse/MODPYTHON-98? page=comments#action_12362399 ] Jim Gallacher commented on MODPYTHON-98: Applied Graham's suggestions so all these related issues can be considered fixed. Still need to write some unit tests before this issue is marked as resolved. Graham, I've committed the following unit tests for MODPYTHON-98: test_req_add_bad_handler test_req_add_empty_handler_string test_accesshandler_add_handler_to_empty_hl Can you take a look and let me know if you think these properly cover the issue? If they look ok I'll roll the 3.2.6 beta. I get a failure on test_req_add_empty_handler_string. I don't know if this is because of other local hacks I have in place or not. But for it to pass I need the following change to the test.py: This test was of some concern, as I thought the error log message might be inconsistent. Index: test.py === --- test.py (revision 368329) +++ test.py (working copy) @@ -516,8 +516,8 @@ f = open(os.path.join(SERVER_ROOT, logs/error_log)) log = f.read() f.close() -if log.find(contains no 'handler') == -1: -self.fail(Could not find contains no 'handler' in error_log) +if log.find(No module named) == -1: +self.fail(Could not find No module named in error_log) def test_accesshandler_add_handler_to_empty_hl_conf(self): # Note that there is no PythonHandler specified in the the VirtualHost The messages in the error log being: [Thu Jan 12 21:39:35 2006] [notice] mod_python: (Re)importing module '' [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : Traceback (most recent call last): [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/mod_python/apache.py, line 284, in HandlerDispatch\nlog=debug) [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/mod_python/apache.py, line 468, in import_module\nf, p, d = imp.find_module(parts[i], path) [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : ImportError: No module named Your error message actually makes more sense, as the last line in my error_log for this exception mentions PIL. I have
Re: [jira] Commented: (MODPYTHON-98) wrong handler supplied to req.add_handler()generateserror
Jim Gallacher wrote ..
It's a strange one. When I move site-packages/PIL to
site-packages/PIL.bak (leaving PIL.pth as is) and run the tests I get
the same output as Graham and Nicolas. I'm just going to ignore this for
the time being and go with a refactored unit test.
I am making a guess that it is because of the following:
~ [510]$ touch .py
~ [511]$ python
Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type help, copyright, credits or license for more information.
import imp
imp.find_module('',None)
(open file '.py', mode 'U' at 0x602e0, '.py', ('.py', 'U', 1))
Ie., look for a .py file in PIL.
Graham
Re: [jira] Commented: (MODPYTHON-98) wrong handler supplied to req.add_handler()generateserror
Graham Dumpleton wrote:
Jim Gallacher wrote ..
It's a strange one. When I move site-packages/PIL to
site-packages/PIL.bak (leaving PIL.pth as is) and run the tests I get
the same output as Graham and Nicolas. I'm just going to ignore this for
the time being and go with a refactored unit test.
I am making a guess that it is because of the following:
~ [510]$ touch .py
~ [511]$ python
Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type help, copyright, credits or license for more information.
import imp
imp.find_module('',None)
(open file '.py', mode 'U' at 0x602e0, '.py', ('.py', 'U', 1))
Ie., look for a .py file in PIL.
There is no .py in site-packages/PIL/ but it does look like the problem
is PIL related.
import imp
imp.find_module('',None)
(None, '/usr/lib/python2.3/site-packages/PIL/', ('', '', 5))
I've changed the unit test to avoid the problem so I don't think it's
worth wasting any more time.
Jim
Re: Windows x64 binaries
Ahh, I don't have Installshield 10, It aint cheap either :/ Eliminating the dependency on the MS dll's is possible in a win32 build so I think i can mange that to in a win64 build :) The installer should basicly only check if it is installing on Windows XP Pro x64 or Windows 2003 Server x64. So that doesn't seem so bad either. I'll have some free time this weekend, I'll see how far i get. x64 is now my default OS so that should make it easier :) Jorge
event MPM status in 2.2
The event MPM is listed in the new features document for 2.2, which rather implies that it should work and is to some degree supported; yet configure will issue the doom and gloom messages about the code being incomplete and that nobody should use it except developers wishing to improve it. (since it's in server/mpm/experimental still) So... which is it? joe
Re: svn commit: r368396 - in /httpd/httpd/branches/2.2.x: build/win32/win32ver.awk include/ap_release.h support/win32/ApacheMonitor.dsp
The one potential issue I forsee; if someone borrowed the AP_STRINGIFY helper in their source code. This only existed in 2.2.0, but if we are aiming at pure source code compatibility (doesn't affect binary compatibility) I'll restore this macro. Comments? Bill Modified: httpd/httpd/branches/2.2.x/include/ap_release.h -/* The numeric compile-time version constants. These constants are the - * authoritative version numbers for APR. - */ -/** Properly quote a value as a string in the C preprocessor */ -#define AP_STRINGIFY(n) AP_STRINGIFY_HELPER(n) -/** Helper macro for AP_STRINGIFY */ -#define AP_STRINGIFY_HELPER(n) #n +#include apr_general.h /* stringify */
[PATCH] Add CachMinExpire
Set a lower limit on expire time for objects with no expires, but have
last-modified.
I have the problem that new objects get ridiculously small expire times
from lastmodifiedfactor, this just sets a floor on it.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
--- mod_cache.c~2005-11-10 10:20:05.0 -0500
+++ mod_cache.c 2006-01-12 12:15:45.0 -0500
@@ -689,6 +689,9 @@
if ((lastmod != APR_DATE_BAD) (lastmod date)) {
apr_time_t x = (apr_time_t) ((date - lastmod) * conf-factor);
+if(x conf-minex) {
+x = conf-minex;
+}
if (x conf-maxex) {
x = conf-maxex;
}
@@ -872,6 +875,8 @@
/* maximum time to cache a document */
ps-maxex = DEFAULT_CACHE_MAXEXPIRE;
ps-maxex_set = 0;
+ps-minex = 0;
+ps-minex_set = 0;
/* default time to cache a document */
ps-defex = DEFAULT_CACHE_EXPIRE;
ps-defex_set = 0;
@@ -908,6 +913,7 @@
overrides-cacheenable);
/* maximum time to cache a document */
ps-maxex = (overrides-maxex_set == 0) ? base-maxex : overrides-maxex;
+ps-minex = (overrides-minex_set == 0) ? base-minex : overrides-minex;
/* default time to cache a document */
ps-defex = (overrides-defex_set == 0) ? base-defex : overrides-defex;
/* factor used to estimate Expires date from LastModified date */
@@ -1082,6 +1088,19 @@
return NULL;
}
+static const char *set_cache_minex(cmd_parms *parms, void *dummy,
+ const char *arg)
+{
+cache_server_conf *conf;
+
+conf =
+(cache_server_conf *)ap_get_module_config(parms-server-module_config,
+ cache_module);
+conf-minex = (apr_time_t) (atol(arg) * MSEC_ONE_SEC);
+conf-minex_set = 1;
+return NULL;
+}
+
static const char *set_cache_defex(cmd_parms *parms, void *dummy,
const char *arg)
{
@@ -1144,6 +1163,8 @@
A partial URL prefix below which caching is disabled),
AP_INIT_TAKE1(CacheMaxExpire, set_cache_maxex, NULL, RSRC_CONF,
The maximum time in seconds to cache a document),
+AP_INIT_TAKE1(CacheMinExpire, set_cache_maxex, NULL, RSRC_CONF,
+ The minimum time in seconds to cache a document),
AP_INIT_TAKE1(CacheDefaultExpire, set_cache_defex, NULL, RSRC_CONF,
The default time in seconds to cache a document),
AP_INIT_FLAG(CacheIgnoreNoLastMod, set_cache_ignore_no_last_mod, NULL,
Re: [jira] Commented: (MODPYTHON-98) wrong handler supplied to req.add_handler() generates error
Hi all, I'm back after a few days without Internet access... I also have the same test failure as Graham. Here is my error log : [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] req_add_empty_handler_string [Thu Jan 12 20:11:24 2006] [notice] mod_python: (Re)importing module '' [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : Traceback (most recent call last): [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : File E:\\Python24\\Lib\\site-packages\\mod_python\\apache.py, line 287, in HandlerDispatch\nlog=debug) [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : File E:\\Python24\\Lib\\site-packages\\mod_python\\apache.py, line 461, in import_module\nf, p, d = imp.find_module(parts[i], path) [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : ImportError: No module named [Thu Jan 12 20:11:25 2006] [notice] mod_python: (Re)importing module 'tests' [Thu Jan 12 20:11:25 2006] [error] [client 127.0.0.1] accesshandler_add_handler_to_empty_hl Regards, Nicolas 2006/1/12, Jim Gallacher [EMAIL PROTECTED]: Graham Dumpleton wrote: On 12/01/2006, at 11:10 AM, Jim Gallacher wrote: Jim Gallacher (JIRA) wrote: [ http://issues.apache.org/jira/browse/MODPYTHON-98? page=comments#action_12362399 ] Jim Gallacher commented on MODPYTHON-98: Applied Graham's suggestions so all these related issues can be considered fixed. Still need to write some unit tests before this issue is marked as resolved. Graham, I've committed the following unit tests for MODPYTHON-98: test_req_add_bad_handler test_req_add_empty_handler_string test_accesshandler_add_handler_to_empty_hl Can you take a look and let me know if you think these properly cover the issue? If they look ok I'll roll the 3.2.6 beta. I get a failure on test_req_add_empty_handler_string. I don't know if this is because of other local hacks I have in place or not. But for it to pass I need the following change to the test.py: This test was of some concern, as I thought the error log message might be inconsistent. Index: test.py === --- test.py (revision 368329) +++ test.py (working copy) @@ -516,8 +516,8 @@ f = open(os.path.join(SERVER_ROOT, logs/error_log)) log = f.read() f.close() -if log.find(contains no 'handler') == -1: -self.fail(Could not find contains no 'handler' in error_log) +if log.find(No module named) == -1: +self.fail(Could not find No module named in error_log) def test_accesshandler_add_handler_to_empty_hl_conf(self): # Note that there is no PythonHandler specified in the the VirtualHost The messages in the error log being: [Thu Jan 12 21:39:35 2006] [notice] mod_python: (Re)importing module '' [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : Traceback (most recent call last): [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/mod_python/apache.py, line 284, in HandlerDispatch\nlog=debug) [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/mod_python/apache.py, line 468, in import_module\nf, p, d = imp.find_module(parts[i], path) [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : ImportError: No module named Your error message actually makes more sense, as the last line in my error_log for this exception mentions PIL. I have *no* idea where that comes from but was hoping that the final line would at least always contain the string contains no 'handler'. Here is my error_log: [Thu Jan 12 08:25:13 2006] [error] [client 127.0.0.1] req_add_empty_handler_string [Thu Jan 12 08:25:13 2006] [notice] mod_python: (Re)importing module '' [Thu Jan 12 08:25:13 2006] [error] [client 127.0.0.1] PythonHandler : Traceback (most recent call last): [Thu Jan 12 08:25:13 2006] [error] [client 127.0.0.1] PythonHandler : File /usr/lib/python2.3/site-packages/mod_python/apache.py, line 291, in HandlerDispatch\narg=req, silent=hlist.silent) [Thu Jan 12 08:25:13 2006] [error] [client 127.0.0.1] PythonHandler : File /usr/lib/python2.3/site-packages/mod_python/apache.py, line 531, in resolve_object\nraise AttributeError, s [Thu Jan 12 08:25:13 2006] [error] [client 127.0.0.1] PythonHandler : AttributeError: module '/usr/lib/python2.3/site-packages/PIL/__init__.pyc' contains no 'handler' Perhaps some other people could check out trunk, run the tests and let me know what shows up in the error_log after the req_add_empty_hander_string line. Thanks, Jim
Re: Apache 2.2.0 on Win32
You are not on the wright track by trying to solve the msjava.dll dependency. Just follow the instructions at: http://msdn2.microsoft.com/en-us/library/ms235291.aspx Steffen http://www.sambarserver.info - Original Message - From: Fenlason, Josh [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, January 12, 2006 8:24 PM Subject: RE: Apache 2.2.0 on Win32 Here is the path that requires msjava.dll: Httpd.exe-libapr-1.dll-advapi32.dll-winsta.dll-netapi32.dll-dnsapi. dll-iphlpapi.dll-mprapi.dll-activeds.dll-adsldpc.dll-credui.dll-sh ell32.dll-shdocvw.dll-mshtml.dll-msjava.dll I found a thread that seemed like it might be on the right track. http://channel9.msdn.com/ShowPost.aspx?PostID=23261 I changed the manifest options mentioned here for the buildbin project, but that didn't solve the dependency. I tried building from the command line with nmake like you suggested, but the build failed with the following error: NMAKE : fatal error U1073: don't know how to make '..\apr\Release\libapr-1.lib' Stop. NMAKE : fatal error U1077: 'D:\ProgramFiles\MicrosoftVisualStudio8\VC\bin\nmake.exe' : return code '0x2' Stop. NMAKE : fatal error U1077: 'D:\ProgramFiles\MicrosoftVisualStudio8\VC\bin\nmake.exe' : return code '0x2' Stop. Any idea what's wrong there? -Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 2:28 PM To: dev@httpd.apache.org Subject: Re: Apache 2.2.0 on Win32 Fenlason, Josh wrote: Yeah, I stumbled upon depends.exe this morning. I used it on the 2k3 box and found out that it couldn't find msjava.dll (Why is this needed for Apache?) and msvcr80.dll. I copied them from the working XP box into apache_home\bin. It found the dlls, but I still get the same error. Interesting. I would be especially interested in knowing which .dll then requires msjava.dll? Follow the depends tree to let us know. Error: The Side-by-Side configuration information in c:\apache22\bin\HTTPD.EXE contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001). Apparently there might be some additional flags that have triggered creation of some built-in manifest? Can you try skipping the gui and doing instead an nmake -f makefile.win clean and nmake -f makefile.win installr ? This won't introduce any new 'features' contained in VisualStudio 2005, which could be introduced by converting the .dsp's into .vcproj's. I don't see any other obvious problems in the Dependency Walker. All the dll's in the Module In List, except the first 17, have little hour glass icons next to them. I don't know if that is an issue or not. Hour glass I presume is delay-load. You are looking for red icons in the function or modules view, which indicate modules or entry points which could not be resolved. I tried running depends.exe on the working box and I noticed the following in the bottom. Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module. This is normal. The kernel itself has some of these conditions. One thing I know is different between the XP boxes is that the working (and build) XP box has SP2 and the nonworking one doesn't? Any possibility that's an issue? Any other input would be welcome. Thanks.
Re: mod_dbd and Windows
mod_dbd together with the apr_dbd framework, is listed in the new features document for 2.2, which rather implies that it should work and is to some degree supported. As far as my and other win users experience, I hade to conclude that mod_dbd/mod_authn_dbd is experimental. Steffen - Original Message - From: Carsten Wiedmann [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Wednesday, January 11, 2006 11:42 PM Subject: Re: mod_dbd and Windows Nick Kew schrieb: On Friday 06 January 2006 19:20, Steffen wrote: Several ppl tried it, but it crashes Apache or it looses connections, see: http://www.apachelounge.com/forum/viewtopic.php?t=52 To get it compiled, as i told you before, mysql.h has to be changed, see: http://www.apachelounge.com/forum/viewtopic.php?p=280#280 Looking at your URL, you've changed __WIN__ to __WIN32__ in mysql.h. That seems to be something internal to MySQL itself, outside the reach of the apr_dbd_mysql driver. I've also tried to use mod_dbd and MySQL on Windows with no luck. I don't must change mysql.h to compile the modules. Instead I must add this line in apr_dbd_mysql.c: | #include mysql/my_global.h before: | #include mysql/mysql.h All build fine (Apache 2.2.0 / MySQL 5.0.18). But every time I access a secured page the Apache child process give up with: | [notice] Parent: child process exited with status 3221225477 -- Restarting. After the automatic restart of the child process and a refresh in the browser I can see the page. Next (an other) page the same thing. I don't know where is the problem. mod_dbd or apr_dbd*? BTW: Have you ever try to use mod_dbd with sqlite2 or sqlite3 on Windows? When i try to use this, I get this message at server startup (and during accessing a page): | [crit] (20014)Internal error: DBD: failed to initialise But I don't realy know if my configuration in httpd.conf is correct for SQLite (there are no examples...). Regards, Carsten Wiedmann
mod_cache performance
Greetings all, I may finally have some time to work on some mod_cache issues that have been nagging me. Mostly performance things. I really want to stop maintaining my own version here, but to do that mod_cache needs to be sped up a bit. I'm setting up a dev environment now, so hopefully I should have something usable soon. Unfortunately, most patches I have submitted for mod_cache have basically been ignored. Are there any general ideas you guys have in where the performance bottlenecks may be? A short list I have (mostly mod_disk_cache): -read_table and read_array seem slower than they should be -thundering herd when a popular object expires -writing out request headers when not varying I have submitted patches for some of these in the past, but I will try to quantify the performance implications of these. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: Apache 2.2.0 on Win32
Fenlason, Josh wrote: Yep, I copied every and modified the configuration files accordingly. I have it working on the XP box that it was built on. It won't run on different XP and 2003 boxes. I compiled it with Visual Studio 2005. (That's what is recommended, right?) Your other boxes are likely to be missing the VS 2005 C runtime. This actually becomes a user question (yes, users list is for help getting apache to build.) In fact we are continuing on with Visual Studio 6, for the time being, so folks can continue to use various things like the modperl etc built upon ActiveState.
Re: Apache 2.2.0 on Win32
Fenlason, Josh wrote: Here is the path that requires msjava.dll: Httpd.exe-libapr-1.dll-advapi32.dll-winsta.dll-netapi32.dll-dnsapi. dll-iphlpapi.dll-mprapi.dll-activeds.dll-adsldpc.dll-credui.dll-sh ell32.dll-shdocvw.dll-mshtml.dll-msjava.dll When you see something nested from MS itself, it's safe to assume; * the dependency is dynamic, and won't trigger a fault if not present or * the dependency is based on that OS's version of libname.dll, and the dependency is not present on another version's. MS owns this dependency; it's not your problem (nor ours). I tried building from the command line with nmake like you suggested, but the build failed with the following error: NMAKE : fatal error U1073: don't know how to make '..\apr\Release\libapr-1.lib' Stop. That's very odd; I'll research.
Any concerns with 2.2.1 by the weekend?
I'm offering to RM this package late friday or sometime Saturday if there's no serious objection. Fixing or not fixing partial page results is obviously not a regression, although I'm happy to wait an extra couple days if the fix has been agreed upon, committed and is only undergoing some extra bashing-upon. Part of the Win32 binaries issue is that the -src.zip still required too much tweaking to be called the official version, by the time i'd finished build/test I'd had to make too many other 'minor tweaks'. I'd feel much warmer releasing 2.2.1 as binaries on Win32, as the build system (now) corresponds to the actual product. I can do one of three things to eliminate awk for generating .rc files; * use one common module .rc file with some /D inputs for module name, etc. * create the dozens of .rc files in svn * have the buildconf create all the .rc files I'm leaning twords the first option. Bill
Re: mod_cache performance
Brian Akins wrote: A short list I have (mostly mod_disk_cache): -read_table and read_array seem slower than they should be -thundering herd when a popular object expires Thundering herd was one of the original design goals of the new cache that was never fully followed through. With the work getting the cache to handle transfer failures gracefully, the next logical step is to solve thundering herd. -writing out request headers when not varying I have submitted patches for some of these in the past, but I will try to quantify the performance implications of these. Submit them to bugzilla to make sure they do not drop on the floor, then nag this list. I will be off the air till the end of the month to have a holiday, but after that I definitely plan to get my hands dirty. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Apache 2.2.0 on Win32
so folks can continue to use various things like the modperl etc built upon ActiveState Using VC6 or VS2005, in both cases you have to rebuild mod_perl for 2.2.0 mod_perl builds out-of-box with VS2005 and is working fine with Apache 2.2.0/Activestate. Till now I did not find any issue not to use VS2005 with Apache 2.2.0 and a lot of third-party mods. I distribute it and is working on all current windows versions. Steffen - Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, January 12, 2006 9:55 PM Subject: Re: Apache 2.2.0 on Win32 Fenlason, Josh wrote: Yep, I copied every and modified the configuration files accordingly. I have it working on the XP box that it was built on. It won't run on different XP and 2003 boxes. I compiled it with Visual Studio 2005. (That's what is recommended, right?) Your other boxes are likely to be missing the VS 2005 C runtime. This actually becomes a user question (yes, users list is for help getting apache to build.) In fact we are continuing on with Visual Studio 6, for the time being, so folks can continue to use various things like the modperl etc built upon ActiveState.
RE: Apache 2.2.0 on Win32
I was finally able to get this working by following the instructions for private assemblies in the link Steffen provided. I will just have to ship the Microsoft.VC80.CRT directory from VS2005 with my binary. I do have one question though. I have to drop the Microsoft.VC80.CRT directory in apache_home\bin and apache_home\modules. Any idea why I have to add it in both places? I even added Microsoft.VC80.CRT to the path and it still had to be in both locations. I can live with this since it's not too big, so I'm just curious. Thanks for all the help. , Josh. -Original Message- From: Steffen [mailto:[EMAIL PROTECTED] Sent: Thursday, January 12, 2006 1:36 PM To: dev@httpd.apache.org Subject: Re: Apache 2.2.0 on Win32 You are not on the wright track by trying to solve the msjava.dll dependency. Just follow the instructions at: http://msdn2.microsoft.com/en-us/library/ms235291.aspx Steffen http://www.sambarserver.info - Original Message - From: Fenlason, Josh [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, January 12, 2006 8:24 PM Subject: RE: Apache 2.2.0 on Win32 Here is the path that requires msjava.dll: Httpd.exe-libapr-1.dll-advapi32.dll-winsta.dll-netapi32.dl l-dnsapi. dll-iphlpapi.dll-mprapi.dll-activeds.dll-adsldpc.dll-cred ui.dll-sh ell32.dll-shdocvw.dll-mshtml.dll-msjava.dll I found a thread that seemed like it might be on the right track. http://channel9.msdn.com/ShowPost.aspx?PostID=23261 I changed the manifest options mentioned here for the buildbin project, but that didn't solve the dependency. I tried building from the command line with nmake like you suggested, but the build failed with the following error: NMAKE : fatal error U1073: don't know how to make '..\apr\Release\libapr-1.lib' Stop. NMAKE : fatal error U1077: 'D:\ProgramFiles\MicrosoftVisualStudio8\VC\bin\nmake.exe' : return code '0x2' Stop. NMAKE : fatal error U1077: 'D:\ProgramFiles\MicrosoftVisualStudio8\VC\bin\nmake.exe' : return code '0x2' Stop. Any idea what's wrong there? -Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 2:28 PM To: dev@httpd.apache.org Subject: Re: Apache 2.2.0 on Win32 Fenlason, Josh wrote: Yeah, I stumbled upon depends.exe this morning. I used it on the 2k3 box and found out that it couldn't find msjava.dll (Why is this needed for Apache?) and msvcr80.dll. I copied them from the working XP box into apache_home\bin. It found the dlls, but I still get the same error. Interesting. I would be especially interested in knowing which .dll then requires msjava.dll? Follow the depends tree to let us know. Error: The Side-by-Side configuration information in c:\apache22\bin\HTTPD.EXE contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001). Apparently there might be some additional flags that have triggered creation of some built-in manifest? Can you try skipping the gui and doing instead an nmake -f makefile.win clean and nmake -f makefile.win installr ? This won't introduce any new 'features' contained in VisualStudio 2005, which could be introduced by converting the .dsp's into .vcproj's. I don't see any other obvious problems in the Dependency Walker. All the dll's in the Module In List, except the first 17, have little hour glass icons next to them. I don't know if that is an issue or not. Hour glass I presume is delay-load. You are looking for red icons in the function or modules view, which indicate modules or entry points which could not be resolved. I tried running depends.exe on the working box and I noticed the following in the bottom. Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module. This is normal. The kernel itself has some of these conditions. One thing I know is different between the XP boxes is that the working (and build) XP box has SP2 and the nonworking one doesn't? Any possibility that's an issue? Any other input would be welcome. Thanks.
Re: Any concerns with 2.2.1 by the weekend?
William A. Rowe, Jr. wrote: I'm offering to RM this package late friday or sometime Saturday if there's no serious objection. Fixing or not fixing partial page results is obviously not a regression, although I'm happy to wait an extra couple days if the fix has been agreed upon, committed and is only undergoing some extra bashing-upon. I'd like the partial page fix to be in 2.2.1 if possible. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: Any concerns with 2.2.1 by the weekend?
On 01/12/2006 09:57 PM, William A. Rowe, Jr. wrote: I'm offering to RM this package late friday or sometime Saturday if there's no serious objection. Fixing or not fixing partial page results is obviously not a regression, although I'm happy to wait an extra couple days if the fix has been agreed upon, committed and is only undergoing some extra bashing-upon. I think the following thing from the backport list must be solved in 2.2.1 (maybe with different patch if the one proposed is not ok): - mod_cache: Fix PR38017 (mod_cache not working in reverse proxy setup?) This is a regression against 2.0.x and makes it impossible to use mod_cache on reverse proxies. I just added this to the showstopper section of the STATUS file. The following from backport list should be fixed: - mod_ssl: Fix PR37791 (CVEID: CAN-2005-3357) (SEGV if the client is connection plain to a SSL enabled port) Although minor, it is a security issue and should be fixed plus it only misses one vote. - The partial pages issue. Although improvements could be made to the current patch I think it solves the actual problem suitable. Improvements could be done later. Anyway I think at least PR38017 and PR37791 can be sorted out very quickly. Apart from the points above I am fine with releasing 2.2.1. Thanks for volunteering as RM Bill. Regards Rüdiger
Re: [PATCH] clarify return value of hook functions used in request processing
On 9/9/05, Daniel L. Rall [EMAIL PROTECTED] wrote: This is a code-clarity improvement only. * server/request.c (ap_process_request_internal): Check the return value of hook functions against the constant OK -- defined in httpd.conf as Module has handled this stage -- instead of against the magic number 0 to improve clarity. Thanks, committed in r368505. -garrett
Re: [jira] Commented: (MODPYTHON-98) wrong handler supplied to req.add_handler()generates error
It's a strange one. When I move site-packages/PIL to site-packages/PIL.bak (leaving PIL.pth as is) and run the tests I get the same output as Graham and Nicolas. I'm just going to ignore this for the time being and go with a refactored unit test. Jim Graham Dumpleton wrote: FWIW, I use Python 2.3 on Mac OS X. Nicolas is probably using Win32 as usual. I mention this as I wouldn't be surprised if different versions of Python on different platforms behaved differently when given strange module names for importing. Take as an example prior case where someone was using a/b for a module name. Ie., directory name, slash, and then module name. This wouldn't work on Mac OS X but did work on Linux. Result was that it allowed loading of a module in a subdirectory without need for use of packages. Not sure what Win32 did. Graham Jim Gallacher wrote .. Ok, this is weird. I've run the tests on a couple of my qemu images and I get the same output as Nicolas and Graham in the error log, but a different output for my development machine. I think I'll rewrite the test to just check the response from the request rather than rooting around in the error_log. The point of the test is to make sure that an exception is raised when req.add_handler(PythonHandler, ) is attempted, so there a couple of different ways to go. I'll make the change and then roll the new beta tarball. Jim Nicolas Lehuen wrote: Hi all, I'm back after a few days without Internet access... I also have the same test failure as Graham. Here is my error log : [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] req_add_empty_handler_string [Thu Jan 12 20:11:24 2006] [notice] mod_python: (Re)importing module '' [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : Traceback (most recent call last): [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : File E:\\Python24\\Lib\\site-packages\\mod_python\\apache.py, line 287, in HandlerDispatch\nlog=debug) [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : File E:\\Python24\\Lib\\site-packages\\mod_python\\apache.py, line 461, in import_module\nf, p, d = imp.find_module(parts[i], path) [Thu Jan 12 20:11:24 2006] [error] [client 127.0.0.1] PythonHandler : ImportError: No module named [Thu Jan 12 20:11:25 2006] [notice] mod_python: (Re)importing module 'tests' [Thu Jan 12 20:11:25 2006] [error] [client 127.0.0.1] accesshandler_add_handler_to_empty_hl Regards, Nicolas 2006/1/12, Jim Gallacher [EMAIL PROTECTED]: Graham Dumpleton wrote: On 12/01/2006, at 11:10 AM, Jim Gallacher wrote: Jim Gallacher (JIRA) wrote: [ http://issues.apache.org/jira/browse/MODPYTHON-98? page=comments#action_12362399 ] Jim Gallacher commented on MODPYTHON-98: Applied Graham's suggestions so all these related issues can be considered fixed. Still need to write some unit tests before this issue is marked as resolved. Graham, I've committed the following unit tests for MODPYTHON-98: test_req_add_bad_handler test_req_add_empty_handler_string test_accesshandler_add_handler_to_empty_hl Can you take a look and let me know if you think these properly cover the issue? If they look ok I'll roll the 3.2.6 beta. I get a failure on test_req_add_empty_handler_string. I don't know if this is because of other local hacks I have in place or not. But for it to pass I need the following change to the test.py: This test was of some concern, as I thought the error log message might be inconsistent. Index: test.py === --- test.py (revision 368329) +++ test.py (working copy) @@ -516,8 +516,8 @@ f = open(os.path.join(SERVER_ROOT, logs/error_log)) log = f.read() f.close() -if log.find(contains no 'handler') == -1: -self.fail(Could not find contains no 'handler' in error_log) +if log.find(No module named) == -1: +self.fail(Could not find No module named in error_log) def test_accesshandler_add_handler_to_empty_hl_conf(self): # Note that there is no PythonHandler specified in the the VirtualHost The messages in the error log being: [Thu Jan 12 21:39:35 2006] [notice] mod_python: (Re)importing module '' [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : Traceback (most recent call last): [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/mod_python/apache.py, line 284, in HandlerDispatch\nlog=debug) [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1] PythonHandler : File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/mod_python/apache.py, line 468, in import_module\nf, p, d = imp.find_module(parts[i], path) [Thu Jan 12 21:39:35 2006] [error] [client 127.0.0.1]
Re: Apache 2.2.0 on Win32
William A. Rowe, Jr. wrote: In fact we are continuing on with Visual Studio 6, for the time being, so folks can continue to use various things like the modperl etc built upon ActiveState. Okay, that was not quite clear and is helpful to know. So you're saying that if we build with the latest MS dev/net studio modules built with MS VC++ 6 won't work? It would be good for the overall Apache community to know what they should build 2.2 with for maximum compatibility with non-open-source modules built by others in the community. Another driver, of course, is leveraging the best compiler/optimizer possible without sacrificing too much compatibility. What's the strategy here? -- Jess Holle
Re: Apache 2.2.0 on Win32
Jess Holle wrote: Okay, that was not quite clear and is helpful to know. So you're saying that if we build with the latest MS dev/net studio modules built with MS VC++ 6 won't work? *potentially*. In practice they should interoperate. In fact mod_aspdotnet already does, it's compiled under Studio .NET (now porting it to Studio 2005) but runs under VC6-built Apache. The basic issue is with handing off clib resources, e.g. malloc()ed memory, FILE * handles (stdio style), etc. There is no issue with apr objects that you don't diddle with, and no issues with native Win32 API objects that you kick around. In fact, it's the same set of issues you get into running a module compiled in debug mode on a release build server, or visa versa. It would be good for the overall Apache community to know what they should build 2.2 with for maximum compatibility with non-open-source modules built by others in the community. Another driver, of course, is leveraging the best compiler/optimizer possible without sacrificing too much compatibility. What's the strategy here? Go back over the December threads. Concensus was (for now) stay with 6.0. Bill
Re: Merging branch authz-dev - Authorization and Access Control 2.3vs. 2.2
OK, try this on for size. Since Order,Allow,Deny are all hooked at
the access_checker stage, we should be able to add these directives back
in and allow them to function normally. The real problem is 'Satisfy'
because it had its fingers into the middle of
ap_process_request_internal(). So to get around this problem, I added
the directive back into mod_authz_host (along with Order,Allow,Deny) and
let it do it thing also. 'Satisfy All' is the default (as it was
before) meaning that if the access_checker fails or the authz_checker
fails, then the entire request fails. But if 'Satisfy Any' is specified
then if the access_checker fails, it makes a note of that fact in the
request_rec-notes and defers to the authz_checker. If the
authz_checker fails, obviously the request fails. But if the request
makes it all the way to the mod_authz_default handler, this handler
checks the note and determines whether or not to authorize or reject the
request based on what the current state of both access control and
authz.
So what this means is that Order,Allow,Deny,Satisfy are back and
*should* function as before along side of the new authz model. This
should resolve the backward compatibility issue with the following
caveat. Both mod_authn_default and mod_authz_default modules must be
loaded. These module implement the catch-all handlers that allow things
to work if no authn or authz is implemented for a Directory or
Location. Otherwise access is automatically denied. What I would like
to see is the above *should* confirmed to be a *do*. In other words, I
am looking for some help testing this. Any takers? So far my testing
shows that things are good.
I'll commit this patch to trunk of nobody sees any glaring issues.
Brad
Index: modules/aaa/mod_authz_host.c
===
--- modules/aaa/mod_authz_host.c(revision 368081)
+++ modules/aaa/mod_authz_host.c(working copy)
@@ -44,22 +44,175 @@
#include netinet/in.h
#endif
+enum allowdeny_type {
+T_ENV,
+T_ALL,
+T_IP,
+T_HOST,
+T_FAIL
+};
+
typedef struct {
- int dummy; /* just here to stop compiler warnings for now. */
+apr_int64_t limited;
+union {
+char *from;
+apr_ipsubnet_t *ip;
+} x;
+enum allowdeny_type type;
+} allowdeny;
+
+/* things in the 'order' array */
+#define DENY_THEN_ALLOW 0
+#define ALLOW_THEN_DENY 1
+#define MUTUAL_FAILURE 2
+
+/** all of the requirements must be met */
+#define SATISFY_ALL 0
+/** any of the requirements must be met */
+#define SATISFY_ANY 1
+/** There are no applicable satisfy lines */
+#define SATISFY_NOSPEC 2
+
+
+typedef struct {
+int order[METHODS];
+apr_array_header_t *allows;
+apr_array_header_t *denys;
+int *satisfy; /* for every method one */
} authz_host_dir_conf;
module AP_MODULE_DECLARE_DATA authz_host_module;
static void *create_authz_host_dir_config(apr_pool_t *p, char *dummy)
{
+int i;
authz_host_dir_conf *conf =
(authz_host_dir_conf *)apr_pcalloc(p,
sizeof(authz_host_dir_conf));
+for (i = 0; i METHODS; ++i) {
+conf-order[i] = DENY_THEN_ALLOW;
+}
+conf-allows = apr_array_make(p, 1, sizeof(allowdeny));
+conf-denys = apr_array_make(p, 1, sizeof(allowdeny));
+conf-satisfy = apr_palloc(p, sizeof(*conf-satisfy) * METHODS);
+for (i = 0; i METHODS; ++i) {
+conf-satisfy[i] = SATISFY_NOSPEC;
+}
+
return (void *)conf;
}
+static const char *order(cmd_parms *cmd, void *dv, const char *arg)
+{
+authz_host_dir_conf *d = (authz_host_dir_conf *) dv;
+int i, o;
+
+if (!strcasecmp(arg, allow,deny))
+o = ALLOW_THEN_DENY;
+else if (!strcasecmp(arg, deny,allow))
+o = DENY_THEN_ALLOW;
+else if (!strcasecmp(arg, mutual-failure))
+o = MUTUAL_FAILURE;
+else
+return unknown order;
+
+for (i = 0; i METHODS; ++i)
+if (cmd-limited (AP_METHOD_BIT i))
+d-order[i] = o;
+
+return NULL;
+}
+
+static const char *satisfy(cmd_parms *cmd, void *dv, const char *arg)
+{
+authz_host_dir_conf *d = (authz_host_dir_conf *) dv;
+int satisfy = SATISFY_NOSPEC;
+int i;
+
+if (!strcasecmp(arg, all)) {
+satisfy = SATISFY_ALL;
+}
+else if (!strcasecmp(arg, any)) {
+satisfy = SATISFY_ANY;
+}
+else {
+return Satisfy either 'any' or 'all'.;
+}
+
+for (i = 0; i METHODS; ++i) {
+if (cmd-limited (AP_METHOD_BIT i)) {
+d-satisfy[i] = satisfy;
+}
+}
+
+return NULL;
+}
+
+static const char *allow_cmd(cmd_parms *cmd, void *dv, const char
*from,
+ const char *where_c)
+{
+authz_host_dir_conf *d = (authz_host_dir_conf *) dv;
+allowdeny *a;
+char *where = apr_pstrdup(cmd-pool, where_c);
+char *s;
+char msgbuf[120];
+apr_status_t rv;
+
+if (strcasecmp(from, from))
+return allow and deny must
Re: mod_cache performance
We tried to solve thundering herd problem wih cache-requester module which I have not committed yet. It is currently available on source forge. I have not found enough time to work on it after summer of code was over as I was busy with my thesis, internship. now I have just relocated to calif recently. So, I should be actively working (in couple of weeks probably) on cache-requester soon once things settle down for me. meanwhile, feel free to use mod-cache-requester if you find it useful. Let me know if I could be of any help. -Parin. On 1/12/06, Graham Leggett [EMAIL PROTECTED] wrote: Brian Akins wrote: A short list I have (mostly mod_disk_cache): -read_table and read_array seem slower than they should be -thundering herd when a popular object expires Thundering herd was one of the original design goals of the new cache that was never fully followed through. With the work getting the cache to handle transfer failures gracefully, the next logical step is to solve thundering herd. -writing out request headers when not varying I have submitted patches for some of these in the past, but I will try to quantify the performance implications of these. Submit them to bugzilla to make sure they do not drop on the floor, then nag this list. I will be off the air till the end of the month to have a holiday, but after that I definitely plan to get my hands dirty. Regards, Graham --
Re: Any concerns with 2.2.1 by the weekend?
William A. Rowe, Jr. wrote: I'm offering to RM this package late friday or sometime Saturday if there's no serious objection. Fixing or not fixing partial page results is obviously Backport of ajp Cookie2 fix from HEAD. * mod_proxy: Fix Cookie2 header problems that originates back from mod_jk. Cookie2 was always sent as Cookie. http://svn.apache.org/viewcvs.cgi?rev=358769view=rev Regards, Mladen.
