[jira] Resolved: (MODPYTHON-191) Tampering with signed cookies.
[ http://issues.apache.org/jira/browse/MODPYTHON-191?page=all ] Graham Dumpleton resolved MODPYTHON-191. Resolution: Fixed Tampering with signed cookies. -- Key: MODPYTHON-191 URL: http://issues.apache.org/jira/browse/MODPYTHON-191 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.2.10 Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 As reported by Andy Pearce in: http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200609.mbox/[EMAIL PROTECTED] Andy Pearce wrote: Hi, I think I might have spotted a slight bug in Session.py. When the 'secret' parameter is supplied to use the SignedCookie class, it appears that __init__ of BaseSession doesn't check the return type of get_cookies(). If I understand the SignedCookie docs correctly, if the cookie value doesn't match its signature, it simply returns the contents as a Cookie rather than a SignedCookie (indicating that the user tampered with their cookie before sending it back). However, there is no check in BaseSession's __init__ that the return of get_cookies() is a SignedCookie in the case that 'secret' is supplied. Perhaps a minor point, but it would seem to make the option of using SignedCookies rather pointless, since the signature isn't being checked. Presumably if the cookie has been tampered with, your only safe option is to throw it away and generate a new one. I think this can be achieved by changing the lines: if cookies.has_key(session_cookie_name): self._sid = cookies[session_cookie_name].value To something like: if cookies.has_key(session_cookie_name): if not secret or type(cookes[session_cookie_name]) \ is Cookie.SignedCookie: self._sid = cookies[session_cookie_name].value I'm fairly new to mod_python, so if I'm mistaken then my apologies, and a quick explanation of why would be very much appreciated! ^_^ Thanks, - Andy Is this correct and should the change suggested appropriate? -- 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] Updated: (MODPYTHON-195) Possible leaking of Win32 event handles when Apache restarted.
[ http://issues.apache.org/jira/browse/MODPYTHON-195?page=all ] Graham Dumpleton updated MODPYTHON-195: --- Fix Version/s: 3.3 Possible leaking of Win32 event handles when Apache restarted. -- Key: MODPYTHON-195 URL: http://issues.apache.org/jira/browse/MODPYTHON-195 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.2.10 Reporter: Graham Dumpleton Fix For: 3.3 Jeff Robins in: http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200610.mbox/[EMAIL PROTECTED] indicates a belief that when an Apache restart is performed on Windows that there are a number of Win32 event handles leaked. His belief is that this seems to be linked to mod_python. -- 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-195) Possible leaking of Win32 event handles when Apache restarted.
[ http://issues.apache.org/jira/browse/MODPYTHON-195?page=comments#action_12447742 ] Graham Dumpleton commented on MODPYTHON-195: Can you see if you can come up with some check based on values of 'initialized' and 'child_init_pool'. First step would be to print out their values amongst your above debug. The 'initialized' flag is in there to work around issues with older Mac OS X versions. That used in combination with whether child_init_pool is still zero or not, indicating parent or child process, may give you enough to work out when to return and not execute the function again. Possible leaking of Win32 event handles when Apache restarted. -- Key: MODPYTHON-195 URL: http://issues.apache.org/jira/browse/MODPYTHON-195 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.2.10 Reporter: Graham Dumpleton Fix For: 3.3 Jeff Robins in: http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200610.mbox/[EMAIL PROTECTED] indicates a belief that when an Apache restart is performed on Windows that there are a number of Win32 event handles leaked. His belief is that this seems to be linked to mod_python. -- 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
Re: MODPYTHON-195
On 04/11/2006, at 12:34 PM, Jeff Robbins wrote: Graham, I haven't had any new ideas about this problem. It is clear that on Windows, mod_python is initialized both in a parent process and more usefully in the child process that spins up the threads that service client requests. The parent process is long-lived and the standard hack to wait for the second call to the ap_hook_post_config is useless because each restart of apache is yet another call (third, fourth, fifth, etc...) and each time there's a leak of one handle. The fix I tested seems reasonable. I know it is dependent on mpm_winnt.c, but, after all, that file is the file responsible for the dual process architecture on windows to begin with. And the fix has an #ifdef win32 so it won't hurt linux users. I'd like you to consider folding it in. I think it is better than having a leak (along with spurious python initialization) on windows. Jeff, can you see if you can come up with a test based on 'initialized' and 'child_init_pool' as I note in: http://issues.apache.org/jira/browse/MODPYTHON-195 If it is only in the parent process you need to skip subsequent calls, perhaps: if (child_init_pool == 0 initialized != 0) return OK; Will have to think about how this may screw up old versions of Mac OS X though which is why initialized was added in the first place. You might include in your debug a call to Py_IsInitialized() so it can be determined if Python thinks it is already initialised. Since your fiddle is working, I'd say it probably is. Also see if main_server is set and not zero as well and whether its value is different to 's' passed as argument to function. Whether it is the same or not may dictate where in function the check to bail out of function needs to be. It may have to go just before the global config and mutexes are created. Graham
Re: MODPYTHON-195
Graham,
The problem on Win32 is that (I believe) we never want to initialize Python
in the persistent parent process. All the web action is in the child
process which is long-lived and it is this child process that maintains the
thread pool which services web requests.
The parent process as far as I can tell sits there to support restarting the
child process and support the Win32 Service Control Manager (SCM) which has
a protocol for how a process must respond to certain messages in order to be
a service on Win32.
I do not know how to use flags alone to distinguish the two processes. The
code I put in is not trying to restrict a call to python_init() to only
happen once in the parent process. It is preventing python_init() from
initializing Python in the parent process.
I hope this clarifies things somewhat.
I want to note here that mpm_winnt.c line 1108 looks like this:
/* AP_PARENT_PID is only valid in the child */
pid = getenv(AP_PARENT_PID);
if (pid)
{
/* This is the child */
This environmental is how it knows to run certain code only in the child
process.
In summary,
if we do not want to run python_init() in the special Win32 parent process,
we need a way to distinguish this parent process from the child process in
which we DO want to run python_init(). The code which maintains this dual
process architecture (undoubtedly in support of the Win32 service
architecture) uses an environmental that it purposefull creates and injects
into the child process AP_PARENT_PID. I don't see how we can do better
than use this same distinguishing characterisic to know not to run
python_init() in the parent process.
- Original Message -
From: Graham Dumpleton [EMAIL PROTECTED]
To: Jeff Robbins [EMAIL PROTECTED]
Cc: python-dev list python-dev@httpd.apache.org
Sent: Tuesday, November 07, 2006 06:02
Subject: Re: MODPYTHON-195
On 04/11/2006, at 12:34 PM, Jeff Robbins wrote:
Graham,
I haven't had any new ideas about this problem. It is clear that on
Windows, mod_python is initialized both in a parent process and more
usefully in the child process that spins up the threads that service
client requests. The parent process is long-lived and the standard hack
to wait for the second call to the ap_hook_post_config is useless
because each restart of apache is yet another call (third, fourth,
fifth, etc...) and each time there's a leak of one handle.
The fix I tested seems reasonable. I know it is dependent on
mpm_winnt.c, but, after all, that file is the file responsible for the
dual process architecture on windows to begin with. And the fix has an
#ifdef win32 so it won't hurt linux users.
I'd like you to consider folding it in. I think it is better than
having a leak (along with spurious python initialization) on windows.
Jeff, can you see if you can come up with a test based on 'initialized'
and
'child_init_pool' as I note in:
http://issues.apache.org/jira/browse/MODPYTHON-195
If it is only in the parent process you need to skip subsequent calls,
perhaps:
if (child_init_pool == 0 initialized != 0)
return OK;
Will have to think about how this may screw up old versions of Mac OS X
though which is why initialized was added in the first place.
You might include in your debug a call to Py_IsInitialized() so it can be
determined if Python thinks it is already initialised. Since your fiddle
is
working, I'd say it probably is.
Also see if main_server is set and not zero as well and whether its value
is different to 's' passed as argument to function. Whether it is the
same
or not may dictate where in function the check to bail out of function
needs
to be. It may have to go just before the global config and mutexes are
created.
Graham
Re: MODPYTHON-195
Graham,
The problem on Win32 is that (I believe) we never want to initialize Python
in the persistent parent process. All the web action is in the child
process which is long-lived and it is this child process that maintains the
thread pool which services web requests.
The parent process as far as I can tell sits there to support restarting the
child process and support the Win32 Service Control Manager (SCM) which has
a protocol for how a process must respond to certain messages in order to be
a service on Win32.
I do not know how to use flags alone to distinguish the two processes. The
code I put in is not trying to restrict a call to python_init() to only
happen once in the parent process. It is preventing python_init() from
initializing Python in the parent process.
I hope this clarifies things somewhat.
I want to note here that mpm_winnt.c line 1108 looks like this:
/* AP_PARENT_PID is only valid in the child */
pid = getenv(AP_PARENT_PID);
if (pid)
{
/* This is the child */
This environmental is how it knows to run certain code only in the child
process.
In summary,
if we do not want to run python_init() in the special Win32 parent process,
we need a way to distinguish this parent process from the child process in
which we DO want to run python_init(). The code which maintains this dual
process architecture (undoubtedly in support of the Win32 service
architecture) uses an environmental that it purposefull creates and injects
into the child process AP_PARENT_PID. I don't see how we can do better
than use this same distinguishing characterisic to know not to run
python_init() in the parent process.
- Original Message -
From: Graham Dumpleton [EMAIL PROTECTED]
To: Jeff Robbins [EMAIL PROTECTED]
Cc: python-dev list python-dev@httpd.apache.org
Sent: Tuesday, November 07, 2006 06:02
Subject: Re: MODPYTHON-195
On 04/11/2006, at 12:34 PM, Jeff Robbins wrote:
Graham,
I haven't had any new ideas about this problem. It is clear that on
Windows, mod_python is initialized both in a parent process and more
usefully in the child process that spins up the threads that service
client requests. The parent process is long-lived and the standard hack
to wait for the second call to the ap_hook_post_config is useless
because each restart of apache is yet another call (third, fourth,
fifth, etc...) and each time there's a leak of one handle.
The fix I tested seems reasonable. I know it is dependent on
mpm_winnt.c, but, after all, that file is the file responsible for the
dual process architecture on windows to begin with. And the fix has an
#ifdef win32 so it won't hurt linux users.
I'd like you to consider folding it in. I think it is better than
having a leak (along with spurious python initialization) on windows.
Jeff, can you see if you can come up with a test based on 'initialized'
and
'child_init_pool' as I note in:
http://issues.apache.org/jira/browse/MODPYTHON-195
If it is only in the parent process you need to skip subsequent calls,
perhaps:
if (child_init_pool == 0 initialized != 0)
return OK;
Will have to think about how this may screw up old versions of Mac OS X
though which is why initialized was added in the first place.
You might include in your debug a call to Py_IsInitialized() so it can be
determined if Python thinks it is already initialised. Since your fiddle
is
working, I'd say it probably is.
Also see if main_server is set and not zero as well and whether its value
is different to 's' passed as argument to function. Whether it is the
same
or not may dictate where in function the check to bail out of function
needs
to be. It may have to go just before the global config and mutexes are
created.
Graham
Re: Who is Representing Apache?
Yes, exactly the issue I am worrying about! More companies need to be developing within Apache, and the new book should help out the situation a bit, but a new book isn't enough. We also need to be at the meetings, spreading the news about what it can do for them. They remember mostly that Apache delivers html and runs CGIs. On 11/7/06, Joachim Zobel [EMAIL PROTECTED] wrote: Am Montag, den 06.11.2006, 09:25 -0800 schrieb Brian McQueen: This awesome Apache thing you guys created is beginning to slide into obscurity, when its actually better now than ever and should be moving more steadily into the forefront. Its no mere web server! This is the unfortunate social process that happens when a software system reaches maturity. During this process the software gets harder to use and develop. You end up with a system that is close to perfection, but is used by a very small number of people. VMS could do things, unix is still trying to reach today (versioning file system, transparent clustering). Who uses TeX? The Oracle database is probably on the same road, and there are quite shure others that come to mind within a few minutes of thinking. Apache is special because it is very widely used, but only a few people know what it can actually do. Sincerely, Joachim
Apache BUG: 36495 : ajp_proxy_connect_backend failure
All I have apache 2.2.0 setup on Solaris and i am running into the same issues as the bug here, any had any updates on this. http://issues.apache.org/bugzilla/show_bug.cgi?id=36495 Error i get is: [Mon Nov 06 16:35:35 2006] [error] proxy: AJP: failed to make connection to backend: 1.1.1.2 [Mon Nov 06 16:36:35 2006] [error] (146)Connection refused: proxy: AJP: attempt to connect to 1.1.1.2:8009 (1.1.1.2) failed [Mon Nov 06 16:36:35 2006] [error] ap_proxy_connect_backend disabling worker for (1.1.1.2) [Mon Nov 06 16:36:35 2006] [error] proxy: AJP: failed to make connection to backend: 1.1.1.2 Does anyone know if this bug was fixed ? --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: Apache BUG: 36495 : ajp_proxy_connect_backend failure
Benjamin Cuthbert wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=36495 Does anyone know if this bug was fixed ? It is in the trunk, where there is alternative socket is_connected detection. Can you check the trunk, or at least copy the new is_socket_connected from tunk's proxy_util.c to the 2.2.x and see if it works. I have tested the new implementation on Solaris, and it works fine. Without that the closed socket by Tomcat is not detected on most platforms. Regards, Mladen.
Re: Apache BUG: 36495 : ajp_proxy_connect_backend failure
Okay i am not sure i follow, so when you say copy the trunk from proxy_util.c do you have the example that you used so that i can put it into my build ? Regards Ben Cuthbert Deutsche Bank AG Corporate Investment Bank GTO : TISO / Arch Global Finance / Prime Services PGP: http://pgp.mit.edu +44 (0) 20 754 76389 (Tel) +44 (0) 20 754 74996 (Fax) Mladen Turk [EMAIL PROTECTED] 11/07/2006 08:18 AM Please respond to dev@httpd.apache.org To dev@httpd.apache.org cc Subject Re: Apache BUG: 36495 : ajp_proxy_connect_backend failure Benjamin Cuthbert wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=36495 Does anyone know if this bug was fixed ? It is in the trunk, where there is alternative socket is_connected detection. Can you check the trunk, or at least copy the new is_socket_connected from tunk's proxy_util.c to the 2.2.x and see if it works. I have tested the new implementation on Solaris, and it works fine. Without that the closed socket by Tomcat is not detected on most platforms. Regards, Mladen. --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Header compression (or lack of) in mod_proxy
Hello all, I'm using Apache as a HTTP proxy. Regarding the request and response headers, I've done some tests and noticed different behaviour in the request and response direction. The request headers are compressed (i.e. headers with same name are merged into one header and comma separated). e.g. hdr: value1 hdr: value2 becomes, hdr: value1, value2 This due to ap_get_mime_headers_core() calling apr_table_compress(). It occurs in protocol.c before Apache even detects that the incoming request is a proxy request. The response headers on the other hand are read by mod_proxy in ap_proxy_read_headers() which calls apr_table_add() but not apr_table_compress(). RFC 2616 states that header compression MUST be allowed, i.e. it's optional, therefore Apache's behaviour is compliant. However if a proxy is between a non-compliant client and/or server then it may be best to leave the headers in their original form. If a direct connection works and a proxied connection fails then the proxy will be perceived as the problem. Could someone point out a reason for the different behaviour in the request and response path? How about making the behaviour configurable so that it's consistent in both directions and if necessary the headers can be left in their original uncompressed form? By the way, my tests were on httpd 2.0.59, however reading the source for 2.2.3 suggests it has same behaviour. Thanks for your time, Paul -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze
Re: Apache BUG: 36495 : ajp_proxy_connect_backend failure
Can you show me where this trunk is ? URL ? Regards Ben Cuthbert Deutsche Bank AG Corporate Investment Bank GTO : TISO / Arch Global Finance / Prime Services PGP: http://pgp.mit.edu +44 (0) 20 754 76389 (Tel) +44 (0) 20 754 74996 (Fax) Mladen Turk [EMAIL PROTECTED] 11/07/2006 09:31 AM Please respond to dev@httpd.apache.org To dev@httpd.apache.org cc Subject Re: Apache BUG: 36495 : ajp_proxy_connect_backend failure Benjamin Cuthbert wrote: Okay i am not sure i follow, so when you say copy the trunk from proxy_util.c do you have the example that you used so that i can put it into my build ? Copy the alternate is_socket_connected code instead the current one. Also, please do not use HTML mails when communicating with ASF. They look pretty nasty when someone browse the archive ;) Regards, Mladen --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: Apache BUG: 36495 : ajp_proxy_connect_backend failure
Benjamin Cuthbert wrote: Can you show me where this trunk is ? URL ? svn export http://svn.apache.org/repos/asf/httpd/httpd/trunk httpd-head Anyhow: http://httpd.apache.org/dev/ Regards, Mladen.
De-Chunking
Hi , i 'm running a third-party web service authentication module that hangs when the request coming from the client is splitted out in different chunks. I don't have access to the module and to the client neither, so I'm thinking to write an input filter that collects all the chunks and pass'em to the downstream filter or handler . Is that possible? Best regards, Chris.
Re: Header compression (or lack of) in mod_proxy
Sorry for the double post, I thought my first post got dropped. But it was my fault because I hadn't subscribed. Anyway more below... - Original Message - From: Graham Leggett [EMAIL PROTECTED] To: dev@httpd.apache.org Subject: confirm subscribe to dev@httpd.apache.org Paul Fee wrote: Could someone point out a reason for the different behaviour in the request and response path? Cookies. Cookie headers cannot be compressed as the RFC says they should be, so proxy works around this by not compressing headers. Thanks for that, now I see the problem. The response could contain a set-cookie header, such as: Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT The problem being the date may contain a , character. Use of this reserved character for a purpose other than separating multiple header values means that the Set-Cookie header can not be compressed. Fortunately in the case of a request, the cookie header will not contain a date, hence the same problem is not present. How about making the behaviour configurable so that it's consistent in both directions and if necessary the headers can be left in their original uncompressed form? In theory, the idea that it be consistent in both directions is not unreasonable - it follows the principle of be lenient in what we accept. Therefore, we've eliminated the idea of calling apr_table_compress() for the response due to set-cookie. Would you foresee any issues with disabling the apr_table_compress() call for the request? I'd like to add the option to leave request headers in the form in which they were received from the client. Today, multiple headers with the same name are compressed when read from the client. Therefore Apache modules reading the headers will see a single string with comma separated values. However modules, in theory, could also add new headers so we could have something like: hdr: value1, value2 hdr: value3 If apr_table_compress() was not called, would that break anything? Would modules expect comma separated values or would they be designed to cope with both representations as RFC2616 says they MUST? If we assume that the rest of Apache will cope with both representations, then disabling the call to apr_table_compress() in ap_get_mime_headers_core() will not cause problems. Of course we should keep it configurable and perhaps have the default set to enabled so as not to force new behaviour on users. Thanks, Paul -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze
Re: De-Chunking
- Original Message - From: Christian V. [EMAIL PROTECTED] To: dev@httpd.apache.org Subject: De-Chunking Date: Tue, 07 Nov 2006 11:24:05 +0100 Hi, I'm running a third-party web service authentication module that hangs when the request coming from the client is splitted out in different chunks. I don't have access to the module and to the client neither, so I'm thinking to write an input filter that collects all the chunks and pass'em to the downstream filter or handler . Is that possible? I would almost expect that if a module's filter is of the appropriate type then is will not see the underlying representation (e.g. chunked or not). However that impression may be due to me usually working with output filter. The same may not be the same for input from the client. Also, Apache 2.2 mod_proxy has a feature to dechunk request bodies, see: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#request-bodies It sounds like your on a web server rather than a proxy, but the mod_proxy implementation may provide you with some clues. Hope that helps, Paul -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze
Apache Controller (not sure what list to post)
I'm working on a small utility for windows to remotly start/stop/restart an apache server. In the future I'd like to add support for viewing logs end editing remote config files. Feedback from the few Alpha testers i have is great. But here is the question. 1) for security i send command + password (of server) wich is optionally encrypted over ssl. (any more secure way to do it?) 2) once its done how would i best get it know to the Apache on windows comunity? PS: program is written in delphi will be free (possibly open source)-- ~Jorge
Re: De-Chunking
On Tue, 07 Nov 2006 11:24:05 +0100 Christian V. [EMAIL PROTECTED] wrote: Hi , i 'm running a third-party web service authentication module that hangs when the request coming from the client is splitted out in different chunks. I don't have access to the module and to the client neither, so I'm thinking to write an input filter that collects all the chunks and pass'em to the downstream filter or handler . Is that possible? It's possible, yes. Whether it'll fix the problem for you is not certain. I'd suggest starting with a quick hack (or a dechunking proxy in front of your server) to test it first, if you really can't get the source. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: De-Chunking
Nick Kew wrote: On Tue, 07 Nov 2006 11:24:05 +0100 Christian V. [EMAIL PROTECTED] wrote: Hi , i 'm running a third-party web service authentication module that hangs when the request coming from the client is splitted out in different chunks. I don't have access to the module and to the client neither, so I'm thinking to write an input filter that collects all the chunks and pass'em to the downstream filter or handler . Is that possible? It's possible, yes. Whether it'll fix the problem for you is not certain. I'd suggest starting with a quick hack (or a dechunking proxy in front of your server) to test it first, if you really can't get the source. Maybe the Proxy will fix it but it will not be the solution, so i think i'm gonna write the module-filter. But i need to know how Apache handle multi chunk request, as im not able to find this information. Is request coming entirely to my filter in the form of bucketbrigades then passed to down-streams module or brigades are passed down as soon as they come? (I hope i explained it well) Tnx a lot, Chris.
PATCH #40075 - using ldap groups that contain DNs and usernames for AuthZ
Hi, I've addressed the feedback I received on my patch from Brad Nicholes as follows: I've restored AuthLDAPGroupAttribute to its former syntax and added a new directive, AuthLDAPGroupAttributeDN, whose attribute type is taken to be dn regardless of the value of AuthLDAPGroupAttributeIsDN. AuthLDAPGroupAttributeDN uses the same syntax as AuthLDAPGroupAttribute for the sake of clarity. Thanks, Johanna
Re: Apache BUG: 36495 : ajp_proxy_connect_backend failure
Hi,
adding to Mladens advice: is it possible, that you are trying to produce
more connections, than configured worker threads on your tomcat connector?
Does the error only show up under high load?
How many connections to 1.1.1.2:8009 in which state do you have, when
the error appears?
netstat -an | fgrep '1.1.1.2.8009' | \
awk '{print $NF}' | sort | uniq -c
How do these numbers relate to the number of threads configured in the
connector elements of your tomcats server.xml?
Regards,
Rainer
Benjamin Cuthbert schrieb:
All
I have apache 2.2.0 setup on Solaris and i am running into the same
issues as the bug here, any had any updates on this.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36495
Error i get is:
[Mon Nov 06 16:35:35 2006] [error] proxy: AJP: failed to make connection
to backend: 1.1.1.2
[Mon Nov 06 16:36:35 2006] [error] (146)Connection refused: proxy: AJP:
attempt to connect to 1.1.1.2:8009 (1.1.1.2) failed
[Mon Nov 06 16:36:35 2006] [error] ap_proxy_connect_backend disabling
worker for (1.1.1.2)
[Mon Nov 06 16:36:35 2006] [error] proxy: AJP: failed to make connection
to backend: 1.1.1.2
Does anyone know if this bug was fixed ?
---
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
Re: PATCH #40075 - using ldap groups that contain DNs and usernames for AuthZ
On 11/7/2006 at 1:07 PM, in message [EMAIL PROTECTED], Johanna Bromberg Craig [EMAIL PROTECTED] wrote: Hi, I've addressed the feedback I received on my patch from Brad Nicholes as follows: I've restored AuthLDAPGroupAttribute to its former syntax and added a new directive, AuthLDAPGroupAttributeDN, whose attribute type is taken to be dn regardless of the value of AuthLDAPGroupAttributeIsDN. AuthLDAPGroupAttributeDN uses the same syntax as AuthLDAPGroupAttribute for the sake of clarity. Thanks, Johann Hopefully I can get some time here soon to take a closer look at it. Brad
Re: Apache BUG: 36495 : ajp_proxy_connect_backend failure
This happens when i have one connection
to the tomcat jboss server.
Regards
Ben Cuthbert
Deutsche Bank AG
Corporate Investment Bank
GTO : TISO / Arch Global Finance / Prime Services
PGP: http://pgp.mit.edu
+44 (0) 20 754 76389 (Tel)
+44 (0) 20 754 74996 (Fax)
Rainer Jung [EMAIL PROTECTED]
11/07/2006 09:51 PM
Please respond to
dev@httpd.apache.org
To
dev@httpd.apache.org
cc
Subject
Re: Apache BUG: 36495 :
ajp_proxy_connect_backend failure
Hi,
adding to Mladens advice: is it possible, that you are trying to produce
more connections, than configured worker threads on your tomcat connector?
Does the error only show up under high load?
How many connections to 1.1.1.2:8009 in which state do you have, when
the error appears?
netstat -an | fgrep '1.1.1.2.8009' | \
awk '{print $NF}' | sort | uniq -c
How do these numbers relate to the number of threads configured in the
connector elements of your tomcats server.xml?
Regards,
Rainer
Benjamin Cuthbert schrieb:
All
I have apache 2.2.0 setup on Solaris and i am running into the same
issues as the bug here, any had any updates on this.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36495
Error i get is:
[Mon Nov 06 16:35:35 2006] [error] proxy: AJP: failed to make connection
to backend: 1.1.1.2
[Mon Nov 06 16:36:35 2006] [error] (146)Connection refused: proxy:
AJP:
attempt to connect to 1.1.1.2:8009 (1.1.1.2) failed
[Mon Nov 06 16:36:35 2006] [error] ap_proxy_connect_backend disabling
worker for (1.1.1.2)
[Mon Nov 06 16:36:35 2006] [error] proxy: AJP: failed to make connection
to backend: 1.1.1.2
Does anyone know if this bug was fixed ?
---
This e-mail may contain confidential and/or privileged information.
If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in
this
e-mail is strictly forbidden.
---
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
