I can see two problems here. The first is that if the target of the
internal redirect is a part of the URL namespace which is under the
control of a different handler, or where ApplicationPath option was set
explicitly to be different, the PYSID would potentially override a valid
pysid
Graham Dumpleton wrote:
I can see two problems here. The first is that if the target of the
internal redirect is a part of the URL namespace which is under the
control of a different handler, or where ApplicationPath option was set
explicitly to be different, the PYSID would potentially override
configure.in makes a big deal about determining AP_SIG_GRACEFUL, which
defaults to SIGUSR1, but uses SIGWINCH on Linux 2.0. But then
mpm_common.c goes ahead and ignores this for actually sending the
signal, SIGUSR1 is hard-coded;
if (!strcmp(dash_k_arg, graceful)) {
if (!running) {
On Wed, Jul 27, 2005 at 12:40:58PM +0100, Colm MacCarthaigh wrote:
configure.in makes a big deal about determining AP_SIG_GRACEFUL, which
defaults to SIGUSR1, but uses SIGWINCH on Linux 2.0. But then
mpm_common.c goes ahead and ignores this for actually sending the
signal, SIGUSR1 is
Colm MacCarthaigh wrote:
configure.in makes a big deal about determining AP_SIG_GRACEFUL, which
defaults to SIGUSR1, but uses SIGWINCH on Linux 2.0. But then
mpm_common.c goes ahead and ignores this for actually sending the
signal, SIGUSR1 is hard-coded;
if (!strcmp(dash_k_arg, graceful)) {
On Wed, Jul 27, 2005 at 12:59:05PM +0100, Joe Orton wrote:
SIGUSR1 is unavailable on Linux 2.0 iff linuxthreads is used, i.e. in a
threaded MPM. It'd be better simply to refuse to allow use of threaded
MPMs on such platforms (which nobody will notice) and allow graceful to
use SIGUSR1
I think he wants the -e flag to httpd. This will log startup errors to
stdout. See LogLevel for the various available levels.
So you can start the server with something like:
% apachectl -e debug -k start
rob
Nick Kew wrote:
Vishal Gupta wrote:
Hi,
I have written a module, and want to
On Wed, Jul 27, 2005 at 09:01:53AM -0400, Bill Stoddard wrote:
+1. Ken Coar and I have looked into the need for a 'graceful shutdown' and
there may even be a patch posted to the dev list using an IPC (so long ago
I don't recall the exact details). Freeing up SIGWINCH sounds like a good
Since 2.0.54, it seems mod_auth_ldap just segfaults on any request if
built against older versions of OpenLDAP, 2.2.20 and earlier (pre-2005).
It looks like this was another regression caused the addition of the
LDAPConnectionTimeout option. (New features, stable branch,
regressions? Hmmm,
Joe Orton wrote:
Since 2.0.54, it seems mod_auth_ldap just segfaults on any request if
built against older versions of OpenLDAP, 2.2.20 and earlier (pre-2005).
It looks like this was another regression caused the addition of the
LDAPConnectionTimeout option. (New features, stable branch,
Graham Leggett wrote:
None at all
- if the v2.0 code can be made more stable this is always a good thing,
but there are lots more problems in the v2.0 code that are fixed in the
v2.2 rewrite.
Roll on httpd v2.2.
Agreed, but some of us need an officially stable Apache with
good LDAP
Jess Holle wrote:
Agreed, but some of us need an /officially /stable Apache with good LDAP
authentication support.
The problem is that the v2.0.x code was not very defensive, which means
a simple failure up front causes an obscure and random crash somewhere
further down in the code. The
Graham Leggett wrote:
Jess Holle wrote:
Agreed, but some of us need an /officially /stable Apache with good
LDAP authentication support.
The problem is that the v2.0.x code was not very defensive, which
means a simple failure up front causes an obscure and random crash
somewhere further
Jess Holle wrote:
I can't argue with this -- as much as I want multiple-provider support
right now. [2.0.54's LDAP largely seems to hold up overall -- as
amazing as that seems...]
Most of the bugs in the LDAP code come about because of bad handling of
timed out connections - meaning you
Graham,
You've hit on a couple of issues I had not considered and I'm trying to
understand the implications.
Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-59?page=comments#action_12316578 ]
Graham Dumpleton commented on MODPYTHON-59:
APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2005-07-19 17:59:17 -0400 (Tue, 19 Jul 2005) $]
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
APACHE 2.1 STATUS: -*-text-*-
Last modified at [$Date: 2005-06-30 16:42:43 -0400 (Thu, 30 Jun 2005) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS
Documentation status is maintained
flood STATUS: -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]
Release:
1.0: Released July 23, 2002
milestone-03: Tagged January 16, 2002
ASF-transfer: Released July 17, 2001
18 matches
Mail list logo
