which both must run well before auth_checker. No other contrast is possible so
assuming this doc is just a typo.
access_checker vs. access_checker_ex is discussed here:
Subject: svn commit: r964156 - in /httpd/httpd/trunk: docs/manual/developer/ include/ modules/aaa/ server/
http://svn.apache.org/viewvc?rev=964156&view=rev
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1511878 13f79535-47bb-0310-9956-ffa450edef68
The MSVC Resource Compiler truncates macro names at char 31.
Since apr_general.h includes apr.h which in turn includes
system headers we get warnings or errors with the Resource
Compiler with newer system headers (VC10 and later) which
have macro names defined with more than 31 chars.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1499742 13f79535-47bb-0310-9956-ffa450edef68
to the output filters, which is bogus in the proxy case. Create a
clean mapping from APR codes to HTTP status codes, and use it where
needed.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1482522 13f79535-47bb-0310-9956-ffa450edef68
with weak validation combined with If-Range and Range headers. Break
out explicit conditional header checks to be useable elsewhere in the
server. Ensure weak validation RFC compliance in the byteranges filter.
Ensure RFC validation compliance when serving cached entities. PR 16142
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1479905 13f79535-47bb-0310-9956-ffa450edef68
full advantage of the event MPM. Enable the ability for a module
to reverse the sense of a poll event from a read to a write or vice
versa.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1470679 13f79535-47bb-0310-9956-ffa450edef68
LDAPConnectionPoolTimeout due to confusion over what "bound" means.
Added some LDAP trace at TRACE5 to track how LDAP connections are
reused and rebound.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1452551 13f79535-47bb-0310-9956-ffa450edef68
Password hash functions must be expensive in order to be secure. But
if they have to be re-evaluated for every request, performance
suffers.
As a minimal remedy, cache the most recent result for every
connection. This gives a great performance boost if a web browser
does many requests on the same connection with the same
user+password. In principle, this may keep the plain text password
around longer than before. But in practice, there won't be much
difference since user+password can already remain in some unused
data bucket for longer than the request duration.
A proper solution still needs to be found for connections from
proxies which may carry requests for many different users.
While it currently only requires the conn_rec, the new
ap_password_validate() function takes username and request_rec to
allow future extensions, like detection of brute-force attempts.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1427548 13f79535-47bb-0310-9956-ffa450edef68
This is a first stab, the checks will likely have to be revised.
For now, we check
* if the request line contains control characters
* if the request uri has fragment or username/password
* that the request method is standard or registered with RegisterHttpMethod
* that the request protocol is of the form HTTP/[1-9]+.[0-9]+,
or missing for 0.9
* if there is garbage in the request line after the protocol
* if any request header contains control characters
* if any request header has an empty name
* for the host name in the URL or Host header:
- if an IPv4 dotted decimal address: Reject octal or hex values, require
exactly four parts
- if a DNS host name: Reject non-alphanumeric characters besides '.' and
'-'. As a side effect, this rejects multiple Host headers.
* if any response header contains control characters
* if any response header has an empty name
* that the Location response header (if present) has a valid scheme and is
absolute
If we have a host name both from the URL and the Host header, we replace the
Host header with the value from the URL to enforce RFC conformance.
There is a log-only mode, but the loglevels of the logged messages need some
thought/work. Currently, the checks for incoming data log for 'core' and the
checks for outgoing data log for 'http'. Maybe we need a way to configure the
loglevels separately from the core/http loglevels.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1426877 13f79535-47bb-0310-9956-ffa450edef68
This reverts r1407643, but changes the syntax of HttpProtocol to
min=0.9|1.0, which is less ambiguous than the previous +0.9|-0.9.
Allowing to configure an arbitrary version range was a bad idea,
because it only checked the version in the request line, without
affecting the semantics of the headers, etc.
A tighter restriction off the version in the request line is still
possible with <If "%{SERVER_PROTOCOL_NUM} ..."> .
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1425366 13f79535-47bb-0310-9956-ffa450edef68
