processing of error responses (4xx, 5xx) will be altered.
PR: 39245
This is based on a patch submitted by Bart van der Schans <schans hippo.nl>
and tweaked slightly by me based on discussions on dev@ since April 2006.
I think rpleum was the first to mention the 1xx issue.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@527969 13f79535-47bb-0310-9956-ffa450edef68
even if no expiration time is specified. Futhermore the query string will not
be used for key generation such that requests to the same URI path, but with
different query strings are mapped to the same cache entity. Turning this
setting to ON violates RFC 2616/13.9 and thus it is turned off by default.
PR: 41484
Submitted by: Fredrik Widlund <fredrik.widlund qbrick.com>
Reviewed by: rpluem
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@504183 13f79535-47bb-0310-9956-ffa450edef68
as a MCacheMinObjectSize of 0 does not make sense and leads to a
signal Floating point exception (8) (division by zero) in
memcache_gdsf_algorithm.
PR: 40576
Submitted by: Xuekun Hu <xuekun.hu gmail.com>
Reviewed by: rpluem
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@469895 13f79535-47bb-0310-9956-ffa450edef68
cache tries to save huge files (greater than RAM). Buckets bigger
than a tuneable threshold are split into smaller buckets before
being passed to mod_disk_cache, etc. PR 39380
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@467655 13f79535-47bb-0310-9956-ffa450edef68
locking method and the lockfile location, I never
liked how AcceptMutex was linked to LockFile. This
seemed unnecessary. Much better to have AcceptMutex
do both as well. Plus, now that we will likely see
other modules require a "standard" way of setting
mutexes, why not have Apache provide that as
an API of sorts.
Anyway, LockFile is now depreciated and AcceptMutex
is now SSLMutex-like. We also provide a short
function that "parses" out a mutex parameter
and strips out the mechanism and lockfile location.
AcceptMutex and SSLMutex is this capability.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@467326 13f79535-47bb-0310-9956-ffa450edef68
into the environment with the name AUTHENTICATE_<COLUMN>. This brings
mod_authn_dbd behaviour in line with mod_authnz_ldap.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@466865 13f79535-47bb-0310-9956-ffa450edef68
set, REMOTE_USER will be set to this attribute, rather than the
username supplied by the user. Useful for example when you want users
to log in using an email address, but need to supply a userid instead
to the backend.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@463427 13f79535-47bb-0310-9956-ffa450edef68
of stupid that DumpIO always logs at Debug, esp when
you consider that it's likely you'll be doing so
in conjunction with SSL... One Big Log is understating
it! :)
Add DumpIOLogLevel to allow one to change the level...
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@463291 13f79535-47bb-0310-9956-ffa450edef68
in our DAV examples (in particular, POST). Also
change <Location> to <Directory> in the docs. This
particular example was not a security problem because
<Location> was being used to *extend* access, rather than
to *restrict* access, but it is better to encourage
people to use <Directory> by default.
PR: 40030
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@433694 13f79535-47bb-0310-9956-ffa450edef68
enough. Try being more explicit.
This does leave the danger that people will clip the <Location>
example as the proper way to do things, when they should be
reading on to the <Directory> example. The <Location> example
is only correct when used in conjunction with Alias.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@433021 13f79535-47bb-0310-9956-ffa450edef68
