Graham Dumpleton wrote:
On 13/09/2006, at 8:45 AM, Jim Gallacher wrote:
Woot Woot Woot! We have our wiki!
http://wiki.apache.org/mod_python/
Now comes the hard part... what the heck are we going to do with it? :)
Ahhh, more work. :-(
Obviously the FAQ stuff can go over there, but I
Graham Dumpleton wrote:
Okay, found the source of the memory leak. The problem goes right back
to 3.1.4 which also has the problem when tested.
...
Now what do we do about 3.2.10? Given that this thing leaks really badly
when triggered shows that no one must be using multiple handler phases
Ruediger Pluem wrote:
Having added the following to my virtual host
location /
reject ip 127.0.0.1
/location
results in a 401 response and the following entries in the error_log
[Mon Jul 24 16:56:03 2006] [error] [client 127.0.0.1] user (null):
authorization
failure for /:
[Mon
Jim Gallacher wrote:
The mod_python 3.2.9-rc2 tarball is available for testing.
Something about the mod_python.util changes has either exposed a bug in
Trac, or introduced a bug into mod_python - I'm not sure which yet.
3.2.x r416547 with r393781 reverted works fine for me
3.2.x r416548 seems
Jim Gallacher wrote:
Max Bowsher wrote:
Jim Gallacher wrote:
The mod_python 3.2.9-rc2 tarball is available for testing.
Something about the mod_python.util changes has either exposed a bug in
Trac, or introduced a bug into mod_python - I'm not sure which yet.
3.2.x r416547 with r393781
Attempting to configure mod_python on a current Debian 'etch' system, or
any other using bash-3.1, fails, with the shell error:
syntax error near unexpected token `('
This has already been fixed in mod_python SVN for 4 months (r376555,
MODPYTHON-122), and backported to 3.2.x (r383362), but has
Jim Gallacher wrote:
Rob Sanderson wrote:
+1
Seconded. We have a kludge in our install script to replace sh with
ksh, but it would be nice to be able to remove this.
Thanks!
Is anyone aware of any issues fixed in trunk that still need to be
backported to 3.2.x? I'll check my notes
MODPYTHON-93, r387693, backported in r393781, changes the API of
mod_python.util.Field().
I think that it would be a very bad thing to change an API in an
incompatible way in a patch release - whilst people are likely to
understand that things may break going from 3.2.x to 3.3.x, they are
quite
Jim Gallacher wrote:
Max Bowsher wrote:
MODPYTHON-93, r387693, backported in r393781, changes the API of
mod_python.util.Field().
I think that it would be a very bad thing to change an API in an
incompatible way in a patch release - whilst people are likely to
understand that things may
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Could someone commit?
Thanks.
Max.
Previously sent:
http://mail-archives.apache.org/mod_mbox/httpd-dev/200603.mbox/[EMAIL PROTECTED]
+1'ed by Brad Nicholes:
http://mail-archives.apache.org/mod_mbox/httpd-dev/200603.mbox/[EMAIL PROTECTED]
[[[
*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
mod_authz_core contains a fiendishly complex data structure, the
'authz_provider_list' (which is actually more like a tree than a list),
which is used to implement the concept of nested
SatisfyOne/SatisfyAll sections.
I've been trying off-and-on for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What is the expected level of source compatibility for authz modules
between 2.2 and 2.3?
I'm confused, as some parts of the authz framework on trunk seem to be
attempting to allow some compatibility, whilst other parts do not.
Clarification would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Max Bowsher wrote:
What is the expected level of source compatibility for authz modules
between 2.2 and 2.3?
I'm confused, as some parts of the authz framework on trunk seem to
be attempting to allow some compatibility, whilst other parts do
Joe Orton wrote:
Found by the Coverity report, this one looks like a real bug:
check_provider_list has a if() branch to handle the passed-in
current_provider being NULL, but never sets it to anything else;
current_provider is later dereferenced unconditionally.
It looks like the
dereferenced unconditionally.
Max Bowsher wrote:
It looks like the authn-provider implementation was cloned to
produce starting point of the authz-provider implementation, and
this code wasn't removed when it became redundant.
All callers of check_provider_list() ensure that they pass a
non-NULL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brad Nicholes wrote:
{ On 3/9/2006 at 10:15:33 am, in message
[EMAIL PROTECTED], Max
Bowsher
[EMAIL PROTECTED] wrote:
(((
since the access control directives 'Allow/Deny' have been folded in
as
providers.
)))
^^^ This bit isn't true
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Max Bowsher wrote:
In httpd-2.2, the check_user_id and auth_checker hooks are only
invoked for requests to which both an AuthType and at least one
Require directive apply.
In httpd-2.3, the check_user_id and auth_checker hooks run
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The available bugzilla components don't take account of the 2.2 and 2.3
auth[nz] changes.
I'd like to suggest the following new components:
mod_authn_file
mod_authz_groupfile
mod_auth_basic
mod_authz_owner
mod_authn_dbd
mod_authz_dbd
mod_authn_core
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In httpd-2.2, the check_user_id and auth_checker hooks are only invoked
for requests to which both an AuthType and at least one Require
directive apply.
In httpd-2.3, the check_user_id and auth_checker hooks run unconditionally.
I'm seeking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Justin Erenkrantz wrote:
--On November 25, 2005 1:08:12 PM + Max Bowsher [EMAIL PROTECTED] wrote:
Is is really appropriate to lock in an inaccurate and confusing module
name for the entire 2.2.x era, just to avoid another beta/RC ?
Good
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brad Nicholes wrote:
[EMAIL PROTECTED]
Isn't it kind of weird and very premature to change the name of a
module
in 2.2, when the rewrite will not occur until 2.4?
Letting 2.2 go out with the name mod_authz_host, would effectively be
flipping the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
William A. Rowe, Jr. wrote:
Joshua Slive wrote:
Joost de Heer wrote:
access control:
is this request permitted, based on where it is being made from
In other words, is the host from which the request comes, authorised
to make this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joshua Slive wrote:
Joost de Heer wrote:
access control:
is this request permitted, based on where it is being made from
In other words, is the host from which the request comes, authorised
to make this request? Hence mod_authz_host.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I would like to put the case for renaming mod_authz_host to mod_access_host.
There is a small but significant division between:
access control:
is this request permitted, based on where it is being made from
and
authorization:
is this request
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nick Kew wrote:
On Sunday 20 November 2005 08:21, Brian Pane wrote:
I've created a new branch off of the httpd trunk:
https://svn.apache.org/repos/asf/httpd/httpd/branches/async-read-dev/
The old async-dev branch is rather out of date at this
William A. Rowe, Jr. wrote:
At 02:13 PM 2/22/2005, Max Bowsher wrote:
William A. Rowe, Jr. wrote:
No, this makes no sense, if I build httpd13 and httpd2 I expect
two different conf files.
Then, how do you manage the other files that apache installs into the
same
directory as httpd.conf ?
We
/httpd.pid ?
(Possibly, you just use the config file to change one, but I'd rather my
httpd package have workable compiled-in defaults, not ones which _need_
runtime fixup.
Max.
At 10:01 AM 2/20/2005, Max Bowsher wrote:
Proposal: Make --with-program-name NOT rename httpd.conf, but DO rename
httpd.pid
Proposal: Make --with-program-name NOT rename httpd.conf, but DO rename
httpd.pid
Since apache installs many config files, these config files are never placed
directly into /etc, since that would be too messy. Rather they go into a
specific subdirectory. Therefore, renaming httpd.conf does not
http://issues.apache.org/bugzilla/show_bug.cgi?id=33627
I've bugzilla-ed a tiny patch - review would be appreciated!
Thanks very much,
Max.
This patch contains three independently-reviewable changes that do not
entirely fix the build on Cygwin, but do make important progress in that
Max Bowsher wrote:
This is an initial posting of a patch for comments.
I will Bugzilla it in a few days if no one has requested any changes.
This patch handles a few independently-reviewable changes that do not
entirely fix the build on Cygwin, but do make important progress in that
direction
This is an initial posting of a patch for comments.
I will Bugzilla it in a few days if no one has requested any changes.
This patch handles a few independently-reviewable changes that do not
entirely fix the build on Cygwin, but do make important progress in that
direction.
* build/install.sh:
BugZilla link:
http://issues.apache.org/bugzilla/show_bug.cgi?id=29740
Tiny, 7 line patch for server/Makefile.in .
At the moment, a bug prevents the use of --with-apr=/usr.
The fix is very simple - please, could someone take a look at it, and commit
it?
It's tiny, shouldn't take long to review.
Justin Erenkrantz wrote:
--On Thursday, February 3, 2005 11:31 PM + Max Bowsher [EMAIL PROTECTED]
wrote:
BugZilla link:
http://issues.apache.org/bugzilla/show_bug.cgi?id=29740
Applied in r151255. Thanks! -- justin
Thanks!
Is it suitably small to be considered for 2.0.x backport?
Max.
BugZilla link:
http://issues.apache.org/bugzilla/show_bug.cgi?id=29740
Tiny, 7 line patch for server/Makefile.in .
At the moment, a bug prevents the use of --with-apr=/usr.
The fix is very simple - please, could someone take a look at it, and commit
it?
It's tiny, shouldn't take long to review.
Mladen Turk wrote:
Trying to:
http://svn.apache.org/
or...
https://svn.apache.org/
could not connect to server (http://svn.apache.org)
Just me or thanksgiving :)
Not just you,
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110149240531222w=2
Max.
André Malo wrote:
* Brian Pane [EMAIL PROTECTED] wrote:
I found that the configure.in in recent releases of PCRE uses some
autoconf macros that won't work unless aclocal is called first to
produce a proper aclocal.m4: AC_PROG_LIBTOOL and AC_LIBTOOL_WIN32_DLL
This buildconf patch fixes it for me
Quoting Ivan Ristic ivanr webkreator com (2004-11-17 17:31:39 GMT):
I've used FastCGI to give individual
users their own PHP engines (since PHP now comes with FastCGI protocol
support built-in).
This sounds useful - would you be willing to share some config file samples?
Max.
BugZilla link:
http://issues.apache.org/bugzilla/show_bug.cgi?id=29740
The linked bug contains a very simple patch, for a bug which prevents the
use of --with-apr=/usr.
Please, could someone take a look at it, and commit it?
It's only 7 touched lines in a single file, so should be quick to do.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29740
Configuring with --with-apr=/usr usually fails. This is because:
The generated exports.c #includes all *.h files found in apr-prefix/include
If apr-prefix == /usr , then this means /usr/include/*.h !!!
On most systems, it's quite likely
Apache is failing to build for me, because of a flaw in the exports.c generation. I am
using an APR and APR-Util pre-installed into
/usr. This causes the generated exports.c to included every *.h file in /usr/include.
Since some of these are C++ only, and others
have conflicting definitions,
40 matches
Mail list logo
