[jira] Resolved: (MODPYTHON-121) The local/remote host tests fail for a virtual hosting system such as OpenVPS.
[ http://issues.apache.org/jira/browse/MODPYTHON-121?page=all ]
Graham Dumpleton resolved MODPYTHON-121:
Fix Version: 3.3
Resolution: Fixed
The local/remote host tests fail for a virtual hosting system such as OpenVPS.
--
Key: MODPYTHON-121
URL: http://issues.apache.org/jira/browse/MODPYTHON-121
Project: mod_python
Type: Bug
Versions: 3.2.7
Reporter: Graham Dumpleton
Assignee: Graham Dumpleton
Priority: Minor
Fix For: 3.3
On a virtual hosting environment such as OpenVPS, localhost does not map to
the IP address 127.0.0.1 but the actual IP of the host.
import socket
socket.gethostbyname(localhost)
'207.126.122.36'
This fact causes various aspects of the test_connection_members() test to
fail. To avoid the problem the test could factor in the actual IP as returned
for localhost. Thus in htdocs/tests.py, could read as follows. This should
be okay on UNIX systems, but should be confirmed as okay on Win32 systems.
def test_connection_members(self):
req = self.req
log = req.log_error
conn = req.connection
log(Examining connection memebers:)
try:
import socket
ip = socket.gethostbyname(localhost)
except:
ip = None
log(connection.base_server: %s % `conn.base_server`)
if type(conn.base_server) is not type(req.server):
self.fail(conn.base_server should be same type as req.server)
log(connection.local_addr: %s % `conn.local_addr`)
if not conn.local_addr[0] in (127.0.0.1, 0.0.0.0, ip):
self.fail(conn.local_addr[0] should be '127.0.0.1' or '0.0.0.0')
log(connection.remote_addr: %s % `conn.remote_addr`)
if not conn.remote_addr[0] in (127.0.0.1, 0.0.0.0, ip):
self.fail(conn.remote_addr[0] should be '127.0.0.1' or
'0.0.0.0')
log(connection.remote_ip: %s % `conn.remote_ip`)
if not conn.remote_ip in (127.0.0.1, ip):
self.fail(conn.remote_ip should be '127.0.0.1')
log(connection.remote_host: %s % `conn.remote_host`)
if conn.remote_host is not None:
self.fail(conn.remote_host should be None)
log(connection.remote_logname: %s % `conn.remote_logname`)
if conn.remote_logname is not None:
self.fail(conn.remote_logname should be None)
log(connection.aborted: %s % `conn.aborted`)
if conn.aborted != 0:
self.fail(conn.aborted should be 0)
log(connection.keepalive: %s % `conn.keepalive`)
if conn.keepalive != 2:
self.fail(conn.keepalive should be 2)
log(connection.double_reverse: %s % `conn.double_reverse`)
if conn.double_reverse != 0:
self.fail(conn.double_reverse should be 0)
log(connection.keepalives: %s % `conn.keepalives`)
if conn.keepalives != 1:
self.fail(conn.keepalives should be 1)
log(connection.local_ip: %s % `conn.local_ip`)
if not conn.local_ip in (127.0.0.1, ip):
self.fail(conn.local_ip should be '127.0.0.1')
log(connection.local_host: %s % `conn.local_host`)
if conn.local_host is not None:
self.fail(conn.local_host should be None)
log(connection.id: %s % `conn.id`)
if conn.id 100:
self.fail(conn.id should not be this high)
log(connection.notes: %s % `conn.notes`)
if `conn.notes` != '{}':
self.fail(conn.notes should be {})
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (MODPYTHON-120) Connection handler test fails on virtual hosting system such as OpenVPS.
[ http://issues.apache.org/jira/browse/MODPYTHON-120?page=all ] Graham Dumpleton resolved MODPYTHON-120: Fix Version: 3.3 Resolution: Fixed Connection handler test fails on virtual hosting system such as OpenVPS. Key: MODPYTHON-120 URL: http://issues.apache.org/jira/browse/MODPYTHON-120 Project: mod_python Type: Bug Components: core Versions: 3.2.7 Reporter: Graham Dumpleton Assignee: Graham Dumpleton Priority: Minor Fix For: 3.3 On a virtual hosting environment such as OpenVPS, localhost does not map to the IP address 127.0.0.1 but the actual IP of the host. import socket socket.gethostbyname(localhost) '207.126.122.36' This fact causes the connection handler test to fail because it sets up the virtual host listener definition as something like: Listen 59180 VirtualHost 127.0.0.1:59180 SetHandler mod_python PythonPath [r'/home/grahamd/mod_python-3.2.7/test/htdocs']+sys.path PythonConnectionHandler tests::connectionhandler /VirtualHost In this case it really needs to be: Listen 59180 VirtualHost 207.126.122.36:59180 SetHandler mod_python PythonPath [r'/home/grahamd/mod_python-3.2.7/test/htdocs']+sys.path PythonConnectionHandler tests::connectionhandler /VirtualHost To accomodate virtual hosting arrangements, the test might be able to be rewritten as: def test_connectionhandler_conf(self): try: ip = socket.gethostbyname(localhost) except: ip = 127.0.0.1 self.conport = findUnusedPort() c = str(Listen(%d % self.conport)) + \ str(VirtualHost(%s:%d % (ip,self.conport), SetHandler(mod_python), PythonPath([r'%s']+sys.path % DOCUMENT_ROOT), PythonConnectionHandler(tests::connectionhandler))) return c This should always work on UNIX boxes, but whether it does on Win32 boxes would need to be confirmed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MODPYTHON-153) Add req.discard_request_body().
[ http://issues.apache.org/jira/browse/MODPYTHON-153?page=comments#action_12372824 ] Graham Dumpleton commented on MODPYTHON-153: Here is the prototype and documentation: /** * In HTTP/1.1, any method can have a body. However, most GET handlers * wouldn't know what to do with a request body if they received one. * This helper routine tests for and reads any message body in the request, * simply discarding whatever it receives. We need to do this because * failing to read the request body would cause it to be interpreted * as the next request on a persistent connection. * @param r The current request * @return error status if request is malformed, OK otherwise */ AP_DECLARE(int) ap_discard_request_body(request_rec *r); Note that by rights, mod_python.publisher and mod_python.psp should both call this method for GET requests. As pointed out in documentation above, if it didn't and GET request contained content then not discarding it can stuff up a following request if a persistent connection is used and multiple requests are pipelined. Add req.discard_request_body(). --- Key: MODPYTHON-153 URL: http://issues.apache.org/jira/browse/MODPYTHON-153 Project: mod_python Type: New Feature Components: core Reporter: Graham Dumpleton Assignee: Graham Dumpleton In HTTP/1.1 any method may include a request body, whereas in HTTP/1.0 only POST and PUT were allowed to. To avoid any potential problems if a handler were trying to emulate in part the default Apache handler for requests, in would be appropriate for a handler to ensure that any request body is discarded. Apache provides a function specifically for this purpose which is called ap_discard_request_body(). For completeness this function should be available in the request object API as req.discard_request_body(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
GET request content and mod_python.publisher/psp.
I have just added to mod_python in subversion a req.discard_request_body() method. This is a direct wrapper for underlying ap_discard_request_body() function in C API. The purpose of the underlying function is as described in documentation attached to prorotype in headers. /** * In HTTP/1.1, any method can have a body. However, most GET handlers * wouldn't know what to do with a request body if they received one. * This helper routine tests for and reads any message body in the request, * simply discarding whatever it receives. We need to do this because * failing to read the request body would cause it to be interpreted * as the next request on a persistent connection. * @param r The current request * @return error status if request is malformed, OK otherwise */ AP_DECLARE(int) ap_discard_request_body(request_rec *r); In other words, the function should be used in GET handlers to get rid of any content in the request. I appreciate that web clients are generally well behaved, but if such content is sent and isn't discarded and keep alives are in use on a connection and requests are pipelined, that content can be wrongly interpreted as being the next request and a failure would thus occur. A robust handler would therefore always call req.discard_request_body() if the request is a GET request. My question is, should mod_python.publisher and mod_python.psp be enhanced and call req.discard_request_body() for a GET request to avoid the posibilities of any problems arising due to a client sending content for a GET request? With the rise of AJAX applications where Javascript is explicitly used to send custom requests, even if it is done inadvertantly and POST should have been used, the risk of having GET requests with content is also probably on the rise. Note that although mod_python.publisher will always apply util.FieldStorage to a request, it only consumes content for a POST request. Same deal with mod_python.psp, although it only processes forms when form variable accessed from PSP page. Thoughts??? Graham
[jira] Resolved: (MODPYTHON-153) Add req.discard_request_body().
[ http://issues.apache.org/jira/browse/MODPYTHON-153?page=all ] Graham Dumpleton resolved MODPYTHON-153: Fix Version: 3.3 Resolution: Fixed New function added, but decision as to whether this function should be called by mod_python.publisher and mod_python.psp for a GET request defered to another time and to be dealt with as separate issue if need be. Add req.discard_request_body(). --- Key: MODPYTHON-153 URL: http://issues.apache.org/jira/browse/MODPYTHON-153 Project: mod_python Type: New Feature Components: core Reporter: Graham Dumpleton Assignee: Graham Dumpleton Fix For: 3.3 In HTTP/1.1 any method may include a request body, whereas in HTTP/1.0 only POST and PUT were allowed to. To avoid any potential problems if a handler were trying to emulate in part the default Apache handler for requests, in would be appropriate for a handler to ensure that any request body is discarded. Apache provides a function specifically for this purpose which is called ap_discard_request_body(). For completeness this function should be available in the request object API as req.discard_request_body(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MODPYTHON-68) Add a readable/writable req.script_name member.
[ http://issues.apache.org/jira/browse/MODPYTHON-68?page=all ] Graham Dumpleton resolved MODPYTHON-68: --- Resolution: Won't Fix Idea of adding req.script_name was withdrawn, so close off issue. Add a readable/writable req.script_name member. --- Key: MODPYTHON-68 URL: http://issues.apache.org/jira/browse/MODPYTHON-68 Project: mod_python Type: New Feature Components: core Versions: 3.2.7 Reporter: Graham Dumpleton Attachments: apache.py.diff The term SCRIPT_NAME in web servers is used to identify that part of a URI which identifies the script handling the request. Within the URI, the SCRIPT_NAME component would be followed by the PATH_INFO component, the latter being potentially an empty string. In mod_python, the value of SCRIPT_NAME could be obtained in a few different ways. These are: 1. Obtain it as req.subprocess_env[SCRIPT_NAME] after having first called req.add_common_vars(). 2. Obtain it as apache.build_cgi_env(req)[SCRIPT_NAME]. This internally calls req.add_common_vars() but then ignores SCRIPT_NAME value from req.subprocess_env and instead tries to calculate it as per (3) below yeilding a different result to (1) in some cases. 3. Attempt to derive it req.uri using code which is based upon something like 'req.uri[:-len(req.path_info)]'. If req.path_info is empty, then the result should be the same as req.uri. All three methods actually yield incorrect results in certain circumstances, with the fact that it occurs in (1) suggesting an underlying Apache bug. The problem area is where there are multiple successive occurrences of '/' appearing in the part of the URI which is used to determine the PATH_INFO value. Looking at some examples for each case we get: req.uri = /~grahamd/handler/mptest.py req.path_info = PATH_INFO = None SCRIPT_NAME (1) = /~grahamd/handler/mptest.py SCRIPT_NAME (2) = /~grahamd/handler/mptest.py SCRIPT_NAME (3) = /~grahamd/handler/mptest.py req.uri = /~grahamd/handler/mptest.py/ req.path_info = / PATH_INFO = / SCRIPT_NAME (1) = /~grahamd/handler/mptest.py SCRIPT_NAME (2) = /~grahamd/handler/mptest.py SCRIPT_NAME (3) = /~grahamd/handler/mptest.py req.uri = /~grahamd/handler/mptest.py// req.path_info = / PATH_INFO = / SCRIPT_NAME (1) = /~grahamd/handler/mptest.py SCRIPT_NAME (2) = /~grahamd/handler/mptest.py/ SCRIPT_NAME (3) = /~grahamd/handler/mptest.py/ req.uri = /~grahamd/handler/mptest.py/a req.path_info = /a PATH_INFO = /a SCRIPT_NAME (1) = /~grahamd/handler/mptest.py SCRIPT_NAME (2) = /~grahamd/handler/mptest.py SCRIPT_NAME (3) = /~grahamd/handler/mptest.py req.uri = /~grahamd/handler/mptest.py/a/b req.path_info = /a/b PATH_INFO = /a/b SCRIPT_NAME (1) = /~grahamd/handler/mptest.py SCRIPT_NAME (2) = /~grahamd/handler/mptest.py SCRIPT_NAME (3) = /~grahamd/handler/mptest.py req.uri = /~grahamd/handler/mptest.py/a//b req.path_info = /a/b PATH_INFO = /a/b SCRIPT_NAME (1) = /~grahamd/handler/mptest.py/a SCRIPT_NAME (2) = /~grahamd/handler/mptest.py/ SCRIPT_NAME (3) = /~grahamd/handler/mptest.py/ req.uri = /~grahamd/handler/mptest.py/a///b req.path_info = /a/b PATH_INFO = /a/b SCRIPT_NAME (1) = /~grahamd/handler/mptest.py/a/ SCRIPT_NAME (2) = /~grahamd/handler/mptest.py/a SCRIPT_NAME (3) = /~grahamd/handler/mptest.py/a req.uri = /~grahamd/handler/mptest.py/a///b//c req.path_info = /a/b/c PATH_INFO = /a/b/c SCRIPT_NAME (1) = /~grahamd/handler/mptest.py/a///b SCRIPT_NAME (2) = /~grahamd/handler/mptest.py/a/ SCRIPT_NAME (3) = /~grahamd/handler/mptest.py/a/ All very strange and not what one would expect. Ignoring the strange results, the first point of creating the tracker item is to propose that a new member be added to the request object referred to as req.script_name. This new member should be both readable and writable. The argument for adding script_name is similar to that for making path_info writable as described in MODPYTHON-67. That is, it would make the task of writing a middleware stack specifically for mod_python but in a similar style to WSGI a slightly simpler task. In adding script_name, it is perhaps suggested that its initial value be somewhat saner than as shown in the results above. More along the lines of: req.uri = /~grahamd/handler/mptest.py// req.path_info = / script_name=/~grahamd/handler/mptest.py req.uri = /~grahamd/handler/mptest.py/a//b req.path_info = /a/b script_name=/~grahamd/handler/mptest.py req.uri = /~grahamd/handler/mptest.py/a///b req.path_info = /a/b script_name=/~grahamd/handler/mptest.py req.uri = /~grahamd/handler/mptest.py/a//b//c req.path_info = /a/b/c script_name=/~grahamd/handler/mptest.py It should perhaps also normalise the path to eliminate duplicate instances of '/' in the URI appearing before the PATH_INFO component. req.uri = /~grahamd/handlermptest.py/a/b/c req.path_info =
Re: [VOTE] Release 2.2.1 as GA
On 2.2.0 (APR 1.2.2) it works ok. Using the same conf with 2.2.1 it gives the error, even the standard printenv.pl is the cgi-bin gives the error. Steffen - Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Sunday, April 02, 2006 05:17 Subject: Re: [VOTE] Release 2.2.1 as GA Steffen wrote: Perl scripts with shebang line are not working on win32, get permature end of script headers error. Steffen, please clarify, is this a regression from 2.2.0 w/ APR 1.2.2? What's your ScriptInterpreterSource say? Bill
Re: [VOTE] Release 2.2.1 as GA
On 04/02/2006 02:40 AM, Jim Jagielski wrote: Ruediger Pluem wrote: Argh. It seems that http://svn.apache.org/viewcvs?rev=379237view=rev has not been backported. My fault not taking more care of this :-(. So I am now -1. Should I propose r379237 for backport? ++1 ! :) Proposed for backport as r390812. Sorry for not noticing earlier that this patch was missing :-(. Regards Rüdiger
mod_proxy_balancer connection pool limitation problem
Hi, I'm suspecting a bug, but posting here first to make sure. I've got a backend server running at machine X (192.168.0.242) and Apache running at machine Y, and I'd like to restrict the number of connections Apache makes to the backend server, but so far without any luck. VirtualHost *:80 ProxyPass /zope http://192.168.0.242:7680/ max=2 timeout=1 acquire=1 ttl=1 /VirtualHost I'm using mpm-worker, both machines are Linux machines. I thought Apache would make no more than 2 connections to the backend server, but lsof on the backend server shows something else: # lsof -i :7680 | wc -l 121 Any ideas? Rgds, Bjorn
Re: mod_proxy_balancer connection pool limitation problem
On 04/02/2006 04:46 PM, Bjørn Stabell wrote: VirtualHost *:80 ProxyPass /zope http://192.168.0.242:7680/ max=2 timeout=1 acquire=1 ttl=1 /VirtualHost I'm using mpm-worker, both machines are Linux machines. I thought Apache would make no more than 2 connections to the backend server, but lsof on the backend server shows something else: The cache limit is per httpd process. How many httpd processes are running? What mpm are you using? Can you check if there are really more than 2 connections per httpd process on the frontend? # lsof -i :7680 | wc -l 121 Are you sure that all of these connections are established? Could you also check netstat -an | egrep :7680.*ESTABLISHED? Regards Rüdiger
Re: [VOTE] Release 2.2.1 as GA
On 04/02/2006 05:19 AM, William A. Rowe, Jr. wrote: Can someone on win32 PLEASE update the .dsp file for apr-util? Glad to Does this mean that httpd 2.2.1 does not run with apr-util below 1.2.6 on windows? Is this desired? Regards Rüdiger
Re: [VOTE] Release 2.2.1 as GA
On Sun, Apr 02, 2006 at 04:57:43PM +0200, Ruediger Pluem wrote: On 04/02/2006 05:19 AM, William A. Rowe, Jr. wrote: Can someone on win32 PLEASE update the .dsp file for apr-util? Glad to Does this mean that httpd 2.2.1 does not run with apr-util below 1.2.6 on windows? I implied that it meant that httpd 2.2.1 will have to wait until = 1.2.7 ships. Is this desired? Adding an ABI doesn't break ABI backwards-compat, so it should be o.k. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: mod_proxy_balancer connection pool limitation problem
Hi Ruediger, On Apr 2, 2006, at 22:54, Ruediger Pluem wrote: On 04/02/2006 04:46 PM, Bjørn Stabell wrote: VirtualHost *:80 ProxyPass /zope http://192.168.0.242:7680/ max=2 timeout=1 acquire=1 ttl=1 /VirtualHost I'm using mpm-worker, both machines are Linux machines. I thought Apache would make no more than 2 connections to the backend server, but lsof on the backend server shows something else: The cache limit is per httpd process. How many httpd processes are running? What mpm are you using? Can you check if there are really more than 2 connections per httpd process on the frontend? # lsof -i :7680 | wc -l 121 Are you sure that all of these connections are established? Could you also check netstat -an | egrep :7680.*ESTABLISHED? I'm running mpm-worker with config: IfModule mpm_worker_module StartServers 2 MaxClients 128 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 64 MaxRequestsPerChild 0 /IfModule # /nb/apache-2.2/bin/httpd -l Compiled in modules: core.c worker.c http_core.c mod_so.c This should give 2 processes, each with 64 threads, right? At the peak, 64 connections are established with the backend: # netstat -an | egrep :7680.*ESTABLISHED | wc -l 64 Btw, since the number of processes is rather indirect with the advent of mpm-worker, and since most people would be most interested in limiting the total number of connections to the backend (to spare the backend), wouldn't it make more sense to limit the total number? Btw2, it wasn't very clear from the docs at http://httpd.apache.org/ docs/2.2/mod/mod_proxy.html that they were per-process maximums. I think most people will read Apache will never create more than the Hard Maximum or max connections to the backend server. as meaning max across all processes and threads. Rgds, Bjorn
Re: [VOTE] Release 2.2.1 as GA
On 04/02/2006 05:06 PM, Colm MacCarthaigh wrote: Adding an ABI doesn't break ABI backwards-compat, so it should be o.k. But httpd 2.2.1 would not compile with apr-util below 1.2.7 on windows. So I guess this part of the code should be conditional and only active either on non windows (BTW: anyone tested if other non UNIX OS are affected by this? Netware?) or if apr-util = 1.2.7 as I remember myself that httpd 2.2.x should compile with any apr / apr-util 1.2.x. Regards Rüdiger
Re: mod_proxy_balancer connection pool limitation problem
On 04/02/2006 05:16 PM, Bjørn Stabell wrote: IfModule mpm_worker_module StartServers 2 MaxClients 128 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 64 MaxRequestsPerChild 0 /IfModule # /nb/apache-2.2/bin/httpd -l Compiled in modules: core.c worker.c http_core.c mod_so.c This should give 2 processes, each with 64 threads, right? At the peak, 64 connections are established with the backend: correct. # netstat -an | egrep :7680.*ESTABLISHED | wc -l 64 Ok, yes there had been some problems with this limit. They should be fixed with 2.2.1. Could you give the tar ball that Paul rolled a try or wait until the release of 2.2.1? Btw, since the number of processes is rather indirect with the advent of mpm-worker, and since most people would be most interested in limiting the total number of connections to the backend (to spare the backend), wouldn't it make more sense to limit the total number? The total number is actually limited by maximum number of processes * max parameter for backend, but I admit that this should be documented more clearly. And on worker MPM maximum number of processes = MaxClients / ThreadsPerChild + 1. I guess what you have in mind is a global cache over the different processes. I think this would require a major refactoring of the proxy code and would make things more complex and error prone for comparable little gain. Regards Rüdiger
Re: [VOTE] Release 2.2.1 as GA
On Sun, Apr 02, 2006 at 05:17:00PM +0200, Ruediger Pluem wrote: On 04/02/2006 05:06 PM, Colm MacCarthaigh wrote: Adding an ABI doesn't break ABI backwards-compat, so it should be o.k. But httpd 2.2.1 would not compile with apr-util below 1.2.7 on windows. That's allowed I think, and I think there are precendents for that too, it's only ABI compatibility for modules that we have to worry about. So I guess this part of the code should be conditional and only active either on non windows (BTW: anyone tested if other non UNIX OS are affected by this? Netware?) or if apr-util = 1.2.7 as I remember myself that httpd 2.2.x should compile with any apr / apr-util 1.2.x. We could ifdef it for that easily enough, so that's a good idea :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Bug report for Apache httpd-1.3 [2006/04/02]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 8329|New|Nor|2002-04-20|mime_magic gives 500 and no error_log on Microsoft| | 8372|Ass|Nor|2002-04-22|Threadsaftey issue in Rewrite's cache [Win32/OS2/N| | 8849|New|Nor|2002-05-07|make install errors as root on NFS shares | | 8882|New|Enh|2002-05-07|[PATCH] mod_rewrite communicates with external rew| | 9037|New|Min|2002-05-13|Slow performance when acessing an unresolved IP ad| | 9126|New|Blk|2002-05-15|68k-next-openstep v. 4.0 | | 9726|New|Min|2002-06-09|Double quotes should be flagged as T_HTTP_TOKEN_ST| | 9894|New|Maj|2002-06-16|getline sub in support progs collides with existin| | |New|Nor|2002-06-19|Incorrect default manualdir value with layout.| |10038|New|Min|2002-06-20|ab benchmaker hangs on 10K https URLs with keepali| |10073|New|Maj|2002-06-20|upgrade from 1.3.24 to 1.3.26 breaks include direc| |10166|Opn|Min|2002-06-24|HTTP/1.1 proxy requests made even when client make| |10169|New|Nor|2002-06-24|Apache seg faults due to attempt to access out of | |10178|New|Maj|2002-06-24|Proxy server cuts off begining of buffer when spec| |10195|New|Nor|2002-06-24|Configure script erroneously detects system Expat | |10199|New|Nor|2002-06-24|Configure can't handle directory names with unders| |10243|New|Maj|2002-06-26|CGI scripts not getting POST data | |10354|New|Nor|2002-06-30|ErrorDocument(.htaccess) fails when passed URL wit| |10446|Opn|Blk|2002-07-03|spaces in link to http server seen as foreign char| |10666|New|Enh|2002-07-10|line-end comment error message missing file name | |10744|New|Nor|2002-07-12|suexec might fail to open log file| |10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i| |10760|New|Maj|2002-07-12|empty ftp directory listings from cached ftp direc| |10939|New|Maj|2002-07-18|directory listing errors | |11020|New|Maj|2002-07-21|APXS only recognise tests made by ./configure | |11236|New|Min|2002-07-27|Possible Log exhaustion bug? | |11265|New|Blk|2002-07-29|mod_rewrite fails to encode special characters| |11765|New|Nor|2002-08-16|.apaci.install.tmp installs in existing httpd.conf| |11986|New|Nor|2002-08-23|Restart hangs when piping logs on rotation log pro| |12096|New|Nor|2002-08-27|apxs does not handle binary dists installed at non| |12574|New|Nor|2002-09-12|Broken images comes from mod_proxy when caching ww| |12583|New|Nor|2002-09-12|First piped log process do not handle SIGTERM | |12598|Opn|Maj|2002-09-12|Apache hanging in Keepalive State | |12770|Opn|Nor|2002-09-18|ErrorDocument fail redirecting error 400 | |13188|New|Nor|2002-10-02|does not configure correctly for hppa64-hp-hpux11.| |13274|Ass|Nor|2002-10-04|Subsequent requests are destroyed by the request e| |13607|Opn|Enh|2002-10-14|Catch-all enhancement for vhost_alias?| |13687|New|Min|2002-10-16|Leave Debug symbol on Darwin | |13822|New|Maj|2002-10-21|Problem while running Perl modules accessing CGI::| |14095|Opn|Nor|2002-10-30|Change default Content-Type (DefaultType) in defau| |14250|New|Maj|2002-11-05|Alternate UserDirs don't work intermittantly | |14443|New|Maj|2002-11-11|Keep-Alive randomly causes TCP RSTs | |14448|Opn|Cri|2002-11-11|Apache WebServer not starting if installed on Comp| |14518|Opn|Nor|2002-11-13|QUERY_STRING parts not incorporated by mod_rewrite| |14670|New|Cri|2002-11-19|Apache didn't deallocate unused memory| |14748|New|Nor|2002-11-21|Configure Can't find DBM on Mac OS X | |15011|New|Nor|2002-12-03|Apache processes not timing out on Solaris 8 | |15028|New|Maj|2002-12-03|RedirectMatch does not escape properly| |16013|Opn|Nor|2003-01-13|Fooling mod_autoindex + IndexIgnore | |16236|New|Maj|2003-01-18|Include directive in Apache is not parsed within c| |16241|New|Maj|2003-01-19|Apache processes takes 100% CPU until killed manua|
Bug report for Apache httpd-2 [2006/04/02]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 7483|Ass|Enh|2002-03-26|Add FileAction directive to assign a cgi interpret| | 7741|Ass|Nor|2002-04-04|some directives may be placed outside of proper co| | 7862|New|Enh|2002-04-09|suexec never log a group name.| | 8483|Inf|Min|2002-04-24|apache_2.0 .msi installer breaks .log and .conf fi| | 8713|New|Min|2002-05-01|No Errorlog on PROPFIND/Depth:Infinity| | 8925|New|Cri|2002-05-09|Service Install (win32 .msi/.exe) fails for port i| | 9727|New|Min|2002-06-09|Double quotes should be flagged as T_HTTP_TOKEN_ST| | 9903|Opn|Maj|2002-06-16|mod_disk_cache does not remove temporary files| | 9945|New|Enh|2002-06-18|[PATCH] new funtionality for apache bench | |10114|Ass|Enh|2002-06-21|Negotiation gives no weight to order, only q value| |10154|Ass|Nor|2002-06-23|ApacheMonitor interferes with service uninstall/re| |10722|Opn|Nor|2002-07-12|ProxyPassReverse doesn't change cookie paths | |10775|Ass|Cri|2002-07-13|SCRIPT_NAME wrong value | |10932|Opn|Enh|2002-07-18|Allow Negative regex in LocationMatch | |11035|New|Min|2002-07-22|Apache adds double entries to headers generated by| |11294|New|Enh|2002-07-30|desired vhost_alias option| |11427|Opn|Maj|2002-08-02|Possible Memory Leak in CGI script invocation | |11540|Opn|Nor|2002-08-07|ProxyTimeout ignored | |11580|Opn|Enh|2002-08-09|generate Content-Location headers | |11971|Opn|Nor|2002-08-23|HTTP proxy header Via with wrong hostname if Ser| |11997|Opn|Maj|2002-08-23|Strange critical errors possibly related to mpm_wi| |12033|Opn|Nor|2002-08-26|Graceful restart immidiately result in [warn] long| |12340|Opn|Nor|2002-09-05|WindowsXP proxy, child process exited with status | |12680|New|Enh|2002-09-16|Digest authentication with integrity protection | |12885|New|Enh|2002-09-20|windows 2000 build information: mod_ssl, bison, et| |13029|New|Nor|2002-09-26|Win32 mod_cgi failure with non-ASCII characters in| |13101|Inf|Cri|2002-09-27|Using mod_ext_filter with mod_proxy and http/1.1 c| |13599|Ass|Nor|2002-10-14|autoindex formating broken for multibyte sequences| |13603|New|Nor|2002-10-14|incorrect DOCUMENT_URI in mod_autoindex with Heade| |13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation | |13946|Inf|Nor|2002-10-24|reverse proxy errors when a document expires from | |13986|Ass|Enh|2002-10-26|remove default MIME-type | |14016|Inf|Nor|2002-10-28|Problem when using mod_ext_filter with ActivePerl | |14090|New|Maj|2002-10-30|mod_cgid always writes to main server error log | |14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR| |14206|New|Nor|2002-11-04|DirectoryIndex circumvents -FollowSymLinks option | |14227|Ass|Nor|2002-11-04|Error handling script is not started (error 500) o| |14496|New|Enh|2002-11-13|Cannot upgrade 2.0.39 - 2.0.43. Must uninstall fi| |14556|Inf|Nor|2002-11-14|mod_cache with mod_mem_cache enabled doesnt cash m| |14858|New|Enh|2002-11-26|mod_cache never caches responses for requests requ| |14922|Ass|Enh|2002-11-28|target is currently hardcoded to 'apache2' | |15045|Ass|Nor|2002-12-04|addoutputfilterbytype doesn't work for defaulted t| |15233|Opn|Nor|2002-12-10|move AddType application/x-x509-ca-cert from ssl.c| |15235|New|Nor|2002-12-10|add application/x-x509-email-cert, application/x-x| |15625|New|Nor|2002-12-23|mention mod_ssl in http://nagoya.apache.org/dist/h| |15626|New|Nor|2002-12-23|mention which modules are part of the (binary) dis| |15631|New|Nor|2002-12-23|mention in httpd.conf that mod_ssl is not included| |15719|Inf|Nor|2002-12-30|WebDAV MOVE to destination URI which is content-ne| |15757|Opn|Nor|2003-01-02|Assumption of sizeof (void*)/int begin equal (64-b| |15857|Opn|Nor|2003-01-07|MUST handle chunked response with a 16385Byte-lo| |15859|Opn|Nor|2003-01-07|wrong Content-Length header is forwarded when de-c|
Re: [VOTE] Release 2.2.1 as GA
Ruediger Pluem wrote: On 04/02/2006 05:19 AM, William A. Rowe, Jr. wrote: Can someone on win32 PLEASE update the .dsp file for apr-util? Glad to Does this mean that httpd 2.2.1 does not run with apr-util below 1.2.6 on windows? Is this desired? IMHO - this was an outright Win32-specific bug on all versions of apr-util since apu_version_get was introduced :-/ Unfortunately, as someone hinted on the #apr channel, it sometimes seems like until a new API is adopted by the httpd project, it's rarely exercised elsewhere :( AFA version mismatches, I see no issue; nobody could possibly run half the 1.2 versions of apr with httpd on OS/X - due to the poll/kqueue issues on and off throughout the development of that branch and the platform's quirks. Is this a huge issue? I doubt it. Almost anyone obtaining httpd.exe obtains a libapr.dll/libaprutil.dll in the same package/binaries/installer. So this can't really become a big issue. Bill
Re: [VOTE] Release 2.2.1 as GA
Colm MacCarthaigh wrote: On Sun, Apr 02, 2006 at 05:17:00PM +0200, Ruediger Pluem wrote: On 04/02/2006 05:06 PM, Colm MacCarthaigh wrote: Adding an ABI doesn't break ABI backwards-compat, so it should be o.k. But httpd 2.2.1 would not compile with apr-util below 1.2.7 on windows. That's allowed I think, and I think there are precendents for that too, it's only ABI compatibility for modules that we have to worry about. Yea - it's allowed. When we decided on 'binary compatibility', we effectively limited ourselves from updating httpd-2.0 to run on apr-1 instead of apr-0.9. how many features in the evolution of httpd-2.0.x require the incremental releases of apr-0.9.x? OTOH - we can't jump to apr-1, reason being that many folks build third party addins to httpd which require predictable, binary compatibility from subversion bump to bump. So to avoid breaking third party modules, we won't be able to jump from apr-1 to, say, apr-2 until a later httpd-2.x verison. So I guess this part of the code should be conditional and only active either on non windows (BTW: anyone tested if other non UNIX OS are affected by this? Netware?) or if apr-util = 1.2.7 as I remember myself that httpd 2.2.x should compile with any apr / apr-util 1.2.x. We could ifdef it for that easily enough, so that's a good idea :) Nah, this was a platform bug all the time on Windows. So they weren't building an acceptable package that matched our doxygen documented api. True? Bill
Re: mod_cgid not able to handle large POST request
I don't have multiple instances of Apache. When I just use the standard httpd.conf with only this directive commeted out I get this error. There is no issue of multiple instances using the same Unix socket. How does the communication between the cgid deamon and httpd deamon happen when the Scriptsock directive is commented out.On 3/31/06, Jeff Trawick [EMAIL PROTECTED] wrote: On 3/31/06, pradeep kumar [EMAIL PROTECTED] wrote: One more detail. I get this error only on commenting out the Scriptsock directive. When I use this directive though I have no trouble in running the script.Is there more than one Apache instance with same ServerRoot, such that using the default ScriptSock results in multiple instances trying touse the same Unix socket?I assume you set Scriptsock to anon-default value?
