mod_python and Apache 2.2.1 release candidate.
FWIW, mod_python (from subversion) passes all tests with the Apache 2.2.1 release candidate on Mac OS X 10.4. Previously the test_global_lock test failed with Apache 2.2.0 because of a bug in the APR library on Mac OS X. Apache 2.2.1 has newer version of APR library which fixes problem. Graham
[jira] Work started: (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 ]
Work on MODPYTHON-121 started by Graham Dumpleton
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
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] Assigned: (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 reassigned MODPYTHON-120: -- Assign To: Graham Dumpleton 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 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] Work started: (MODPYTHON-120) Connection handler test fails on virtual hosting system such as OpenVPS.
[ http://issues.apache.org/jira/browse/MODPYTHON-120?page=all ] Work on MODPYTHON-120 started by Graham Dumpleton 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 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] Assigned: (MODPYTHON-111) Sessions don't set accessed time on read
[ http://issues.apache.org/jira/browse/MODPYTHON-111?page=all ] Graham Dumpleton reassigned MODPYTHON-111: -- Assign To: Graham Dumpleton (was: Jim Gallacher) Sessions don't set accessed time on read Key: MODPYTHON-111 URL: http://issues.apache.org/jira/browse/MODPYTHON-111 Project: mod_python Type: Bug Components: documentation, session Versions: 3.1.4 Environment: Suse 10, Apache2 worker Reporter: Sebastjan Trepca Assignee: Graham Dumpleton When you read or access session it does not set new accessed time so it eventually dies(depends on the timeout). It only sets the accessed time when you save the session and that is not how sessions normally function(at least not on all other systems). IMHO it should set its accessed time when it was actually accessed and not only when saved. A bit more about this issue can be found here: http://www.modpython.org/pipermail/mod_python/2006-January/019889.html -- 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] Work started: (MODPYTHON-111) Sessions don't set accessed time on read
[ http://issues.apache.org/jira/browse/MODPYTHON-111?page=all ] Work on MODPYTHON-111 started by Graham Dumpleton Sessions don't set accessed time on read Key: MODPYTHON-111 URL: http://issues.apache.org/jira/browse/MODPYTHON-111 Project: mod_python Type: Bug Components: documentation, session Versions: 3.1.4 Environment: Suse 10, Apache2 worker Reporter: Sebastjan Trepca Assignee: Graham Dumpleton When you read or access session it does not set new accessed time so it eventually dies(depends on the timeout). It only sets the accessed time when you save the session and that is not how sessions normally function(at least not on all other systems). IMHO it should set its accessed time when it was actually accessed and not only when saved. A bit more about this issue can be found here: http://www.modpython.org/pipermail/mod_python/2006-January/019889.html -- 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-111) Sessions don't set accessed time on read
[ http://issues.apache.org/jira/browse/MODPYTHON-111?page=all ] Graham Dumpleton resolved MODPYTHON-111: Fix Version: 3.3 Resolution: Fixed Autosave not implemented as described, but documentation updated to add additional note about need to save session to avoid timeout occuring. Sessions don't set accessed time on read Key: MODPYTHON-111 URL: http://issues.apache.org/jira/browse/MODPYTHON-111 Project: mod_python Type: Bug Components: documentation, session Versions: 3.1.4 Environment: Suse 10, Apache2 worker Reporter: Sebastjan Trepca Assignee: Graham Dumpleton Fix For: 3.3 When you read or access session it does not set new accessed time so it eventually dies(depends on the timeout). It only sets the accessed time when you save the session and that is not how sessions normally function(at least not on all other systems). IMHO it should set its accessed time when it was actually accessed and not only when saved. A bit more about this issue can be found here: http://www.modpython.org/pipermail/mod_python/2006-January/019889.html -- 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
[STATUS] (httpd-2.0) Wed Mar 29 23:46:52 2006
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2006-03-27 04:31:07 -0500 (Mon, 27 Mar 2006) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS Documentation status is maintained seperately and can be found at: * docs/STATUS in this source tree, or * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS Consult the following STATUS files for information on related projects: * http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x/STATUS * http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x/STATUS Consult the trunk/ for all new development and documentation efforts: * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS Release history: 2.0.56 : in development 2.0.55 : released October 16, 2005 as GA. 2.0.54 : released April 17, 2005 as GA. 2.0.53 : released February 7, 2005 as GA. 2.0.52 : released September 28, 2004 as GA. 2.0.51 : released September 15, 2004 as GA. 2.0.50 : released June 30, 2004 as GA. 2.0.49 : released March 19, 2004 as GA. 2.0.48 : released October 29, 2003 as GA. 2.0.47 : released July 09, 2003 as GA. 2.0.46 : released May 28, 2003 as GA. 2.0.45 : released April 1, 2003 as GA. 2.0.44 : released January 20, 2003 as GA. 2.0.43 : released October 3, 2002 as GA. 2.0.42 : released September 24, 2002 as GA. 2.0.41 : rolled September 16, 2002. not released. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the bug database at: http://issues.apache.org/bugzilla/ * Review the PatchAvailable bugs in the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable After testing, you can append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: * Forward binary compatibility is expected of Apache 2.0.x releases, such that no MMN major number changes will occur. Such changes can only be made in the trunk. * All commits to branches/2.0.x must be reflected in SVN trunk, as well, if they apply. Logical progression is commit to trunk, get feedback and votes on list or in STATUS, then merge into branches/2.2.x, and finally merge into branches/2.0.x, as applicable. RELEASE SHOWSTOPPERS: * Awaiting next apr-util release to address licensing concerns. PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] *) mod_speling: Don't crash if r-filename is unset. http://svn.apache.org/viewcvs.cgi?rev=385580view=rev +1: trawick, niq, colm PATCHES PROPOSED TO BACKPORT FROM TRUNK: [ please place SVN revisions from trunk here, so it is easy to identify exactly what the proposed changes are! Add all new proposals to the end of this list. ] *) Reverse Proxy fixes: Location bug and Cookie support Patch is at http://people.apache.org/~colm/httpd-2.0-reverse-proxy-cookie.patch and is in production with Clients. +1: niq *) mod_cgid: Fix PR 36410. Invoke the set_suexec_identity hook from the non-cgid side of the handler, where the full
[STATUS] (httpd-2.1) Wed Mar 29 23:47:20 2006
APACHE 2.3 STATUS: -*-text-*-
Last modified at [$Date: 2006-02-02 16:28:52 -0500 (Thu, 02 Feb 2006) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS
Documentation status is maintained seperately and can be found at:
* docs/STATUS in this source tree, or
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS
Consult the following STATUS files for information on related projects:
* http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
* http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS
Patches considered for backport are noted in their branches' STATUS:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
Release history:
[NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
while x.{even}.z versions are Stable/GA releases.]
2.3.0 : in development
Contributors looking for a mission:
* Just do an egrep on TODO or XXX in the source.
* Review the bug database at: http://issues.apache.org/bugzilla/
* Review the PatchAvailable bugs in the bug database:
https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2keywords=PatchAvailable
After testing, you can append a comment saying Reviewed and tested.
* Open bugs in the bug database.
CURRENT RELEASE NOTES:
RELEASE SHOWSTOPPERS:
* Handling of non-trailing / config by non-default handler is broken
http://marc.theaimsgroup.com/?l=apache-httpd-devm=105451701628081w=2
jerenkrantz asks: Why should this block a release?
wsanchez agrees: this may be a change in behavior, but isn't
clearly wrong, and even if so, it doesn't seem like a
showstopper.
* the edge connection filter cannot be removed
http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2
jerenkrantz asks: Why should this block a release?
stas replies: because it requires a rewrite of the filters stack
implementation (you have suggested that) and once 2.2 is
released you can't do that anymore.
CURRENT VOTES:
* If the parent process dies, should the remaining child processes
gracefully self-terminate. Or maybe we should make it a runtime
option, or have a concept of 2 parent processes (one being a
hot spare).
See: Message-ID: [EMAIL PROTECTED]
Self-destruct: Ken, Martin, Lars
Not self-destruct: BrianP, Ian, Cliff, BillS
Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd
/* The below was a concept on *how* to handle the problem */
Have 2 parents: +1: jim
-1: Justin, wrowe, rederpj, nd
+0: Lars, Martin (while standing by, could it do
something useful?)
* Make the worker MPM the default MPM for threaded Unix boxes.
+1: Justin, Ian, Cliff, BillS, striker, wrowe, nd
+0: BrianP, Aaron (mutex contention is looking better with the
latest code, let's continue tuning and testing), rederpj, jim
-0: Lars
pquerna: Do we want to change this for 2.2?
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
* Patches submitted to the bug database:
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable
* Filter stacks and subrequests, redirects and fast redirects.
There's at least one PR that suffers from the current unclean behaviour
(which lets the server send garbage): PR 17629
nd says: Every subrequest should get its own filter stack with the
subreq_core filter as bottom-most. That filter does two things:
- swallow EOS buckets
- redirect the data stream to the upper request's (rr-main)
filter chain directly after the subrequest's starting
point.
Once we have a clean solution, we can try to optimize
it, so that the server won't be slow down too much.
* RFC 2616 violations.
Closed PRs: 15857.
Open PRs: 15852, 15859, 15861, 15864, 15865, 15866, 15868, 15869,
15870, 16120, 16125, 16126, 16133, 16135, 16136, 16137,
16138, 16139, 16140, 16142, 16518, 16520, 16521,
jerenkrantz says: need to decide how many we need to backport and/or
if these rise to showstopper status.
wrowe suggests: it would be nice to see MUST v.s. SHOULD v.s. MAY
out of this list, without reviewing them individually.
* There is a bug in how we sort some hooks, at
httpd 2.0.5x apr_ldap and mod_ldap (util_ldap.c) considerations
Hello, Sending it here, because mod_ldap is distributed (as experimental), with apache distribution I have. This is not a bug report, but a question what's the sense however it's probably discussion starting point When I tried to use ldap_cache provided by ldap_module in my development works, I noticed, that this cache: a. is not assigned per ldc ldap connection object - I mean all util_ldap_connectio_t uses the sam cache. I'm not sure whether its OK, from developer point of view, You'd rather expect to another/new connection doesn't use a cache of previously used (currently active or not), connection. E.g. if I'd like to use two ldap connection independently, I'd expect they'll have separate cache, or at least be able to set in module configuration, whether I want to use global cache for all connections, or separate cache for each connection.. b. inside an ldap connection, I do parametrized search ( base, scope etc.) util_ldap_cache_getuserdn call, and assign search result to some result object, like this: result = util_ldap_cache_getuserdn(r, ldc, conf-url, some_base_dn, LDAP_SCOPE_XXX, char* attributes[], filtbuff, dn, resultval); Next, within the same connection, when I do the same assignment again, but I replace some_base_dn with some_another_base_dn, I still have the same object in result. So, to have differents result with different searches within the same connection, I have to setup CacheTTL to 0, which makes ldap_cache useless. Even, if I create a completely new connection, and within new connection I do a search with just basedn changed in comparison to previous one, I still have the same object from cache. If I set cachettl to 0, everything works fine, but cache is completely useless :(. I guess, that cached entries for a search, are related to a particular search, but matched against this search filter, not against filter _AND_ basedn - searches with the same filter, but different base dn are not the same searches! c. What about apr_ldap and util_ldap in general? It's quite useful anyway, however it seems, that they've been designed to do some particular operations with ldap, but not to add general ldap support to httpd. Currently I miss _very_ much a simple function which would return me an entry object, with char * object_distinguished_name argument, probably as some apr_table would be beatiful.. Instead, if I want to use mod_ldap cache, I need to play with getuserdn function, which actually returns only and exactly ONE entry (if found), or nothing at all (if not found, or if found more than 1 entry). Of course I could use ldap.h SDK, however they're not util_ldap cached, and, in this way, I use two different kinds of ldap connections / object retrieving methods. Or leave util_ldap completely.. So, some simple read_only method implementing some ldap_get_object would be ideal, regarding to above issues.. Thanks for Your comments :) P.
Re: httpd 2.0.5x apr_ldap and mod_ldap (util_ldap.c) considerations
Piotr Wadas wrote: Sending it here, because mod_ldap is distributed (as experimental), with apache distribution I have. mod_auth_ldap and mod_ldap were significantly refactored and many bugs were fixed between v2.0.x and v2.2.x. Backporting the fixes to v2.0.x wasn't practical at the time (they needed to be split between httpd and apr), so you'll probably find most of the issues you describe have already been fixed. I recommend if you intend to use the mod_ldap stuff, use v2.2.x. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r390599 - /httpd/httpd/branches/2.2.x/STATUS
[EMAIL PROTECTED] wrote: Author: pquerna Date: Fri Mar 31 22:33:47 2006 New Revision: 390599 URL: http://svn.apache.org/viewcvs?rev=390599view=rev Log: I am not comfortable with this solution for making the flushing band aid configurable. I do not oppose the concept, just the placement of the configuration information inside of the mod_proxy core, and not in mod_proxy_ajp. The main reason why it's in mod_proxy (and the various elements renamed from ajp_foo to foo) is that as we extend mod_proxy for other protocols, same packet-based like AJP, this will likely be a common problem. Even in non-packet based protocols, I can see wanting some level of admin control. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
fcgi branch
Topic for discussion: merge mod_proxy_fcgi into trunk... I think we're pretty close... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http:// www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: fcgi branch
On 4/1/06, Jim Jagielski [EMAIL PROTECTED] wrote: Topic for discussion: merge mod_proxy_fcgi into trunk... I think we're pretty close... +1 There are a number of improvements I'd like to make eventually (fcgistarter needs a good way to let you signal the running fcgi processes to restart or shut down, we need a way to use unix domain sockets instead of tcp sockets, mod_proxy_fcgi eventually needs a way to manage its own worker processes, etc), but it is at that sort of minimal acceptable functionality stage, and there's no reason to continue to keep it sequestered on the branch. Thank you for bringing this up, I've been meaning to do so for a while now and just haven't gotten around to it yet. -garrett
[VOTE] Release 2.2.1 as GA
2.2.1, embedding APR 1.2.6 and APR-Util 1.2.6, is available from: http://httpd.apache.org/dev/dist/ Please Test and Vote on releasing 2.2.1 as GA. MD5s: f330230636926d08872d84343b08fa16 httpd-2.2.1.tar.bz2 63e7f3e24adda0888a48a247b4eb5613 httpd-2.2.1.tar.gz Thanks, Paul
Re: [VOTE] Release 2.2.1 as GA
On Sat, Apr 01, 2006 at 11:28:15AM -0800, Paul Querna wrote: 2.2.1, embedding APR 1.2.6 and APR-Util 1.2.6, is available from: http://httpd.apache.org/dev/dist/ m Please Test and Vote on releasing 2.2.1 as GA. +1, passes all tests on ubuntu. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [VOTE] Release 2.2.1 as GA
+1: OS X 10.4.5 (gcc4 and gcc3) +1: Solaris 8 (gcc3) Passes all perl-framework tests On Apr 1, 2006, at 2:28 PM, Paul Querna wrote: 2.2.1, embedding APR 1.2.6 and APR-Util 1.2.6, is available from: http://httpd.apache.org/dev/dist/ Please Test and Vote on releasing 2.2.1 as GA. MD5s: f330230636926d08872d84343b08fa16 httpd-2.2.1.tar.bz2 63e7f3e24adda0888a48a247b4eb5613 httpd-2.2.1.tar.gz Thanks, Paul
Re: [VOTE] Release 2.2.1 as GA
On Sat, Apr 01, 2006 at 11:28:15AM -0800, Paul Querna wrote: 2.2.1, embedding APR 1.2.6 and APR-Util 1.2.6, is available from: http://httpd.apache.org/dev/dist/ Please Test and Vote on releasing 2.2.1 as GA. Tests ok on Solaris 10 (U2-beta, sunstudio) vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: [VOTE] Release 2.2.1 as GA
No go on win32: unresolved external symbol [EMAIL PROTECTED] referenced in function _show_compile_settings .\Release/httpd.exe : fatal error LNK1120 Steffen - Original Message - From: Paul Querna [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Saturday, April 01, 2006 21:28 Subject: [VOTE] Release 2.2.1 as GA 2.2.1, embedding APR 1.2.6 and APR-Util 1.2.6, is available from: http://httpd.apache.org/dev/dist/ Please Test and Vote on releasing 2.2.1 as GA. MD5s: f330230636926d08872d84343b08fa16 httpd-2.2.1.tar.bz2 63e7f3e24adda0888a48a247b4eb5613 httpd-2.2.1.tar.gz Thanks, Paul
Re: [VOTE] Release 2.2.1 as GA
lördagen den 1 april 2006 21.28 skrev Paul Querna: 2.2.1, embedding APR 1.2.6 and APR-Util 1.2.6, is available from: http://httpd.apache.org/dev/dist/ Please Test and Vote on releasing 2.2.1 as GA. MD5s: f330230636926d08872d84343b08fa16 httpd-2.2.1.tar.bz2 63e7f3e24adda0888a48a247b4eb5613 httpd-2.2.1.tar.gz Thanks, Paul I get these failed tests with perl-framework (r390750) on Mandriva Linux: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/proxy.t 172 58 33.72% 3 8-9 12-13 16-17 20-21 24-25 28- 29 32-33 36-37 40-41 44-45 48-49 52-53 56-57 115-116 118-120 122 124 126 128 130 132 134 136 138 140 142 144 146 148 150 152 154 156 159-160 163-164 167-168 171- 172 -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
Re: PR 31759 - default handler returns output filter apr_status_t value
On 03/31/2006 06:53 PM, Jeff Trawick wrote: Some concerns about the else path: a) is 500 proper? should it just return OK instead? I think 500 is good. b) what about logging that path to ensure that the administrator has some help diagnosing the problem, since we can't carry the apr_status_t any further than here? There are concerns of too much logging (filter has already logged something) or too little logging (filter didn't log anything). The access log won't have any strong hints that something bad happened since r-status didn't get changed and c-aborted didn't get set. What about the debug level for this log message? Would this be a compromise between too much logging and no logging? Regards Rüdiger
Re: [VOTE] Release 2.2.1 as GA
On 04/01/2006 09:28 PM, Paul Querna wrote: 2.2.1, embedding APR 1.2.6 and APR-Util 1.2.6, is available from: http://httpd.apache.org/dev/dist/ Please Test and Vote on releasing 2.2.1 as GA. +1, compiled and started on RHAS 3 update 3, gcc 3.2.3, glibc 2.3.2, kernel 2.4.21 RHAS 4 update 2, gcc 3.4.4, glibc 2.3.4, kernel 2.6.9 SuSE Linux 8.1, gcc 3.2.2, glibc 2.2.5, kernel 2.4.21
Re: PR 31759 - default handler returns output filter apr_status_t value
On 4/1/06, Ruediger Pluem [EMAIL PROTECTED] wrote: On 03/31/2006 06:53 PM, Jeff Trawick wrote: Some concerns about the else path: a) is 500 proper? should it just return OK instead? I think 500 is good. b) what about logging that path to ensure that the administrator has some help diagnosing the problem, since we can't carry the apr_status_t any further than here? There are concerns of too much logging (filter has already logged something) or too little logging (filter didn't log anything). The access log won't have any strong hints that something bad happened since r-status didn't get changed and c-aborted didn't get set. What about the debug level for this log message? Would this be a compromise between too much logging and no logging? yep ;) I'll move the patch to trunk, change it to return OK where original patch returned r-status, integrate your logging patch, and commit, if it holds up under more varied testing.
Re: [VOTE] Release 2.2.1 as GA
On 4/1/06, Steffen [EMAIL PROTECTED] wrote: No go on win32: unresolved external symbol [EMAIL PROTECTED] referenced in function _show_compile_settings .\Release/httpd.exe : fatal error LNK1120 Didn't a Windows guy make that change? (duck)
Re: [VOTE] Release 2.2.1 as GA
On 04/01/2006 11:24 PM, Oden Eriksson wrote: I get these failed tests with perl-framework (r390750) on Mandriva Linux: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/proxy.t 172 58 33.72% 3 8-9 12-13 16-17 20-21 24-25 28- 29 32-33 36-37 40-41 44-45 48-49 52-53 56-57 115-116 118-120 122 124 126 128 130 132 134 136 138 140 142 144 146 148 150 152 154 156 159-160 163-164 167-168 171- 172 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? Regards Rüdiger
Re: PR 31759 - default handler returns output filter apr_status_t value
On 04/02/2006 12:27 AM, Jeff Trawick wrote: yep ;) I'll move the patch to trunk, change it to return OK where original patch returned r-status, integrate your logging patch, and commit, if it holds up under more varied testing. Thanks.
Re: [VOTE] Release 2.2.1 as GA
söndagen den 2 april 2006 00.32 skrev Ruediger Pluem: On 04/01/2006 11:24 PM, Oden Eriksson wrote: I get these failed tests with perl-framework (r390750) on Mandriva Linux: Failed Test Stat Wstat Total Fail Failed List of Failed - -- t/ssl/proxy.t 172 58 33.72% 3 8-9 12-13 16-17 20-21 24-25 28- 29 32-33 36-37 40-41 44-45 48-49 52-53 56-57 115-116 118-120 122 124 126 128 130 132 134 136 138 140 142 144 146 148 150 152 154 156 159-160 163-164 167-168 171- 172 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? That fixed it for me. -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
Re: [VOTE] Release 2.2.1 as GA
In the Change log: *) Add APR/APR-Util Compiled and Runtime Version numbers to the output of 'httpd -V'. [William Rowe] After removing this in main.c then it builds fine with VC2005 Steffen - Original Message - From: Jeff Trawick [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Sunday, April 02, 2006 00:29 Subject: Re: [VOTE] Release 2.2.1 as GA On 4/1/06, Steffen [EMAIL PROTECTED] wrote: No go on win32: unresolved external symbol [EMAIL PROTECTED] referenced in function _show_compile_settings .\Release/httpd.exe : fatal error LNK1120 Didn't a Windows guy make that change? (duck)
Re: [VOTE] Release 2.2.1 as GA
Perl scripts with shebang line are not working on win32, get permature end of script headers error. Btw. mod_perl is working fine. Steffen http://www.apachelounge.com - Original Message - From: Paul Querna [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Saturday, April 01, 2006 21:28 Subject: [VOTE] Release 2.2.1 as GA 2.2.1, embedding APR 1.2.6 and APR-Util 1.2.6, is available from: http://httpd.apache.org/dev/dist/ Please Test and Vote on releasing 2.2.1 as GA. MD5s: f330230636926d08872d84343b08fa16 httpd-2.2.1.tar.bz2 63e7f3e24adda0888a48a247b4eb5613 httpd-2.2.1.tar.gz Thanks, Paul
Re: [VOTE] Release 2.2.1 as GA
Jeff Trawick wrote: On 4/1/06, Steffen [EMAIL PROTECTED] wrote: No go on win32: unresolved external symbol [EMAIL PROTECTED] referenced in function _show_compile_settings .\Release/httpd.exe : fatal error LNK1120 Didn't a Windows guy make that change? (duck) It looks like this is because apu_version.c is not even present in the Win32 build system. libaprutil.dsp doesn't mention it at all. Can someone on win32 PLEASE update the .dsp file for apr-util? Thanks, -Paul
Re: [VOTE] Release 2.2.1 as GA
Oden Eriksson wrote: I get these failed tests with perl-framework (r390750) on Mandriva Linux: =46ailed Test Stat Wstat Total Fail Failed List of Failed =2D= =2D- t/ssl/proxy.t 172 58 33.72% 3 8-9 12-13 16-17 20-21 24-25 = 28- 29 32-33 36-37 40-41 44-45 48-= 49 52-53 56-57 115-116 118-120 122 124 126 128 130 132 134 136 138 140 142 144 146 148 150 152 154 156 159-160 163-164 167-168 17= 1- 172 Hmmm... I don't have ssl on my test OS X and Sol systems. But I'm guessing it's related to SNV Rev 379237 -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [VOTE] Release 2.2.1 as GA
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 ! :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
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
Paul Querna wrote: Jeff Trawick wrote: On 4/1/06, Steffen [EMAIL PROTECTED] wrote: No go on win32: unresolved external symbol [EMAIL PROTECTED] referenced in function _show_compile_settings .\Release/httpd.exe : fatal error LNK1120 Outch Didn't a Windows guy make that change? (duck) You think I develop on Win32? chuckle/ Actually this patch was introduced primarily for how mismatched things are getting with many projects potentially dropping in some libapr[util].so's onto user's machines. Didn't even ponder the issue on Win32. It looks like this is because apu_version.c is not even present in the Win32 build system. libaprutil.dsp doesn't mention it at all. That would be a problem Can someone on win32 PLEASE update the .dsp file for apr-util? Glad to
Re: [VOTE] Release 2.2.1 as GA
VC++ 2005 (plus msdev.exe) from the command line (makefile.win); OpenSSL 0.98a, manual manifest embedding. main.obj : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _show_compile_settings Release/httpd.exe : fatal error LNK1120: 1 unresolved externals Error executing link.exe. no problems after removing the reference to that function. mod_authn_alias mod_authz_owner were not built. -- Gustavo Lopes
