incomplete and not backportable, fix it by introducing NOT_IN_DIR_CONTEXT and
restoring NOT_IN_DIR_LOC_FILE to its previous value.
Per ap_check_cmd_context(), NOT_IN_DIR_LOC_FILE actually/really means "not in
any directory context", while the definition itself does not include all the
existing directory contexts (e.g. <Limit>, or <Proxy> before r1740928).
This is a bit of a misnomer, at least, so instead of (ab)using it by adding the
missing contexts (in an incompatible way), let's define NOT_IN_DIR_CONTEXT to
really exclude all directory context (i.e. NOT_IN_DIR_LOC_FILE + NOT_IN_LIMIT +
NOT_IN_PROXY) and use it wherever NOT_IN_DIR_LOC_FILE was used.
This is by itself a major MMN bump (modules not compiled with this commit and
having directives checked against NOT_IN_DIR_LOC_FILE won't be caught the same
way by NOT_IN_DIR_CONTEXT in the new ap_check_cmd_context() code), but with the
below change, 2.4.x should work as before:
- if ((forbidden & NOT_IN_DIR_CONTEXT) == NOT_IN_DIR_CONTEXT) {
+ if ((forbidden & NOT_IN_DIR_LOC_FILE) == NOT_IN_DIR_LOC_FILE) {
if (cmd->path != NULL) {
return apr_pstrcat(cmd->pool, cmd->cmd->name, gt,
- " cannot occur within directory context", NULL);
+ " cannot occur within <Directory/Location/Files/Proxy> "
+ "section", NULL);
}
...
}
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1812193 13f79535-47bb-0310-9956-ffa450edef68
to allow proper Vary header insertion when
dealing with a RewriteRule in a directory
context.
This change is an attempt to fix a long standing problem,
brought up while working on PR 58231. Our documentation clearly
states the following:
"If a HTTP header is used in a condition this header is added
to the Vary header of the response in case the condition
evaluates to true for the request."
This is currently not true for RewriteCond/Rules working in
a directory context, since when an internal redirect happens
all the outstanding response headers get dropped.
There might be a better solution so I am looking forward to
hear more opinions and comments. My goal for a delicate change
like this one would be to affect the least amount of configurations
possible, without triggering unwanted side effects.
If the solution is good for everybody tests will be written
in the suite asap.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1811744 13f79535-47bb-0310-9956-ffa450edef68
(r1757672 in 2.4.x)
We iterate over all the values of the registery, so there is no need anymore to have a special case for "HEAD" in 'make_allow()'. It has its own entry now.
With the current code, we have "HEAD" 3 times in the Allow Header field.
This is because we find M_GET 2 times in the registry hash. The first one gives "GET" and "HEAD" (as the special handling), and the second "HEAD" and "HEAD" (as the special handling).
BTW, use APR_ARRAY_PUSH instead of hand coding it, in oder to have the code more readable.
PR 61207
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1799784 13f79535-47bb-0310-9956-ffa450edef68
The C-L header can be set in a fcgi/cgi backend or in other
filters like ap_content_length_filter (with the value of 0),
meanwhile the message-body can be returned incorrectly
by any backend. The idea is to remove unnecessary bytes
from a HTTP 204 response.
PR 51350
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1773346 13f79535-47bb-0310-9956-ffa450edef68
- avoid looping between ap_die and the http filter
- remove the header that failed the check
- keep calling apr_table_do until our fn stops matching
This is still not great. We get the original body, a 500 status
code and status line.
(r1773285 + fix for first return from check_headers)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1773293 13f79535-47bb-0310-9956-ffa450edef68
- avoid looping between ap_die and the http filter
- remove the header that failed the check
- keep calling apr_table_do until our fn stops matching
This is still not great. We get the original body, a 500 status
code and status line.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1773285 13f79535-47bb-0310-9956-ffa450edef68
https://tools.ietf.org/html/rfc7231#section-7.1.2
The "Location" header field is used in some responses to refer to a
specific resource in relation to the response. The type of
relationship is defined by the combination of request method and
status code semantics.
Location = URI-reference
The field value consists of a single URI-reference. When it has the
form of a relative reference ([RFC3986], Section 4.2), the final
value is computed by resolving it against the effective request URI
([RFC3986], Section 5).
There is even an example with no scheme:
Location: /People.html#tim
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1770786 13f79535-47bb-0310-9956-ffa450edef68
Function casts can cause hard-to-debug corruption issues if a
declaration is accidentally changed to be incompatible. Luckily, most of
the function casts for apr_table_do() calls are unnecessary. Remove
them, and adjust the signatures for helpers that weren't taking void* as
the first argument.
The remaining helper that requires a cast is http_filter.c's
form_header_field(), which is probably where many of these casts were
copy-pasted from. I have left it as-is: it has other direct callers
besides apr_table_do(), and it's already documented with warnings not to
change the function signature.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1769192 13f79535-47bb-0310-9956-ffa450edef68
with the implied *LWS rule, before RFC7230 eliminated the later. Whether
this is actually OWS or BWS is an editorial decision beyond our pay grade.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1765475 13f79535-47bb-0310-9956-ffa450edef68
and inefficient application at that, added ap_scan_vchar_obstext()
to accomplish a similar purpose.
Dropped HttpProtocolOptions StrictURL option, this will be better
handled in the future with a specific directive and perhaps multiple
levels of scrutiny, use ap_scan_vchar_obstext() to simply ensure there
are no control characters or whitespace within the URI.
Changed the scanning of the response header table by check_headers()
to follow the same rulesets as reading request headers. Disallow any
CTL character within a response header value, and any CTL or whitespace
in response header field name, even in strict mode.
Apply HttpProtocolOptions Strict to chunk header parsing, invalid
whitespace is invalid, line termination must follow CRLF convention.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1764961 13f79535-47bb-0310-9956-ffa450edef68
to EnforceHTTPProtocol, and invert the default behavior
to strictly observe RFC 7230 unless otherwise configured.
And Document This.
The relaxation option is renamed 'Unsafe'. 'Strict' is no
longer case sensitive. 'min=0.9|1.0' is now the verbose
'Allow0.9' or 'Require1.0' case-insenstive grammer. The
exclusivity tests have been modified to detect conflicts.
The 'strict,log' option failed to enforce strict conformance,
and has been removed. Unsafe, informational logging is possible
in any loadable module, after the request data is unsafely
accepted.
This triggers a group of failures in t/apache/headers.t as
expected since those patterns violated RFC 7230 section 3.2.4.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1756540 13f79535-47bb-0310-9956-ffa450edef68
Export [ap_]check_pipeline() and use it also for ap_proxy_check_connection(),
so that all the necessary checks on the connection are done before reusing it.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1756186 13f79535-47bb-0310-9956-ffa450edef68
