Hi all,
I already know that whenever, say, an access checker hook in a module
returns something like HTTP_FORBIDDEN, the other access checkers from
other modules will not be called. However, will the subsequent hooks
be called (like the fixups)?
Thank you in advance,
--
César L. B. Silveira
On 11.04.2008 01:34, Brad Nicholes wrote:
It is protected by the code at the beginning of util_ldap_post_config()
that calls apr_pool_userdata_get() and checks a user data tag. If the
tag is empty then this is the first time that the function was called.
It then puts something in the tag and
On 11.04.2008 04:00, Chris Darroch wrote:
Ruediger Pluem wrote:
The implementation of the function. IMHO it must be the same in all
modules. Otherwise it depends on the module load order what gets
called and done.
True -- an alternative might be to do the following:
- #define
Author: jorton
Date: Tue Apr 8 08:47:48 2008
New Revision: 645978
URL: http://svn.apache.org/viewvc?rev=645978view=rev
Log:
Adjust socache init interface to take sizing hints, and namespace tag
for memcache:
* modules/cache/ap_socache.h (struct ap_socache_hints): New structure.
Change
Hi Chris,
True -- an alternative might be to do the following:
- #define AUTHN/Z_PROVIDER_VERSION 0 in mod_auth.h
- change all the authn/z modules to use #defines in place of hard-coded
0 provider versions (maybe not a bad thing to do anyway)
- #include mod_auth.h in request.c (mostly
So here's a thought from Davi's^WColm's APR talk in speaking with
chipig, jorton and others...
We have several inheritance quirks addressed by 1.3.0 apr, and the
new memcache, ssl and other features are present in 1.3. The features
in APR[-util] 1.3 would be a definite benefit, today.
When we
On 4/11/08 10:39 AM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
So if APR ships 1.3.0 - would we be prepared to accept 1.3.0 as the new
minimum version, modulo the minor MMN bump?
+1
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
On 11 Apr 2008, at 15:39, William A. Rowe, Jr. wrote:
So if APR ships 1.3.0 - would we be prepared to accept 1.3.0 as the
new
minimum version, modulo the minor MMN bump?
-0.9
People who want 1.3 can get it for themselves.
People who want packages want stable. And there's stuff in 1.3
Guenter Knauf wrote:
We recently found that at least for Win32 install we missed to pack a bunch of
mod_*.h includes with the distros (Bill fixed this then, and this reminds me
that I should do same for NetWare...); however I'm asking me why we dont just
put those mod_*.h files which are
On Fri, Apr 11, 2008 at 4:39 PM, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
So if APR ships 1.3.0 - would we be prepared to accept 1.3.0 as the new
minimum version, modulo the minor MMN bump?
+1. -- justin
So if APR ships 1.3.0 - would we be prepared to accept 1.3.0 as the new
minimum version, modulo the minor MMN bump?
+1
BTW. wouldnt it make sense to introduce a similar versioning as we now use with
httpd?
I mean that current trunk 1.3.0-unstable becomes 1.4.0-stable, and we start on
Roy T. Fielding wrote:
New features belong in modules so that they don't get compiled into
the server by those of us who don't want that feature. I don't recall
why or how KeptBodySize made it into http_filter (where it does not
belong),
but I am quite certain that the core will not be
On Apr 11, 2008, at 8:46 PM, Graham Leggett wrote:
Roy T. Fielding wrote:
New features belong in modules so that they don't get compiled into
the server by those of us who don't want that feature. I don't
recall
why or how KeptBodySize made it into http_filter (where it does
not belong),
Ruediger Pluem wrote:
So we are using the optional function only because we do not have the defines
for AUTHN_PROVIDER_GROUP and the version number around in request.c. If they
would be around it would be quite fine to call ap_list_provider_names directly
from there, correct?
Yes, and in
Furthermore from a first glance of mod_sed I would guess that it runs into
trouble with large static files. So could you test mod_sed with one of
the simple cases above and a 3 GB file and monitor httpd's memory consumption
in comparison to mod_substitute?
I did testing with large files.
Hi,
Yes, and in fact, there's no need for a function call at all, you
can just look up the provider list directly in that case. Much cleaner,
except for all the config magic changes (as discussed by others);
I can more or less guarantee that I'll break the Windows and/or the
Netware
Hi,
in order to simplify future configuration, and most important to have same
include path structure with both in-tree and installed compilations I think it
makes sense to move all mod_*.h headers with public APIs to the common
./include folder.
Current votes:
+1 wrowe, fuankg
please vote,
Guenter Knauf wrote:
in order to simplify future configuration, and most important to have same
include path structure with both in-tree and installed compilations I think it
makes sense to move all mod_*.h headers with public APIs to the common
./include folder.
Current votes:
+1 wrowe,
Guenter Knauf wrote:
in order to simplify future configuration, and most important to
have same include path structure with both in-tree and installed
compilations I think it makes sense to move all mod_*.h headers with
public APIs to the common ./include folder.
+1 since it simplifies my
19 matches
Mail list logo
