Introduces the syntax "%{:<word>:}", borrowed from the <var>'s one, and which
likewise can be embedded anywhere in a string expression (the same reserved
character ':' gets reused in an unambiguous manner).
This allows the two types of expressions (boolean and string) to now share
fully the same language set, namely: strings, lists, vars, regexes, backrefs,
functions with multiple or complex arguments, and especially combinations
thereof.
Most of them were reserved to boolean expressions only, while complex string
constructions can also benefit to, well, strings. The <word> construct allows
that (say the syntax "%{:<word>:}" looks like a temporary variable constructed
in a string).
Since string expressions may now have to deal with lists (arrays), they also
need a way to produce/extract strings from list and vice versa. This can be
done with the new "join" and "split" operators, while the new substitution
regexes (like "s/<pattern>/<substitute>/<flags>") may be used to manipulate
strings in place. All this of course available for both string and boolean
expressions.
Tests and doc updates upcoming..
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1810605 13f79535-47bb-0310-9956-ffa450edef68
This is a follow up of r1808746 after a chat
with Yann on dev@:
- the HTTP:Host variable suffers from the same problem
- the strcasecmp should be used to allow case-sensitive
comparisons.
- in mod_rewrite is less cumbersome and more clean to just
make the Host header check in lookup_header, so it will
be automatically picked up by every part of the code
that uses it. It shouldn't be a relevant overhead for
mod_rewrite.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1809028 13f79535-47bb-0310-9956-ffa450edef68
In PR 58231 is was brought up that httpd adds the
Vary: Host header whenever a condition is set to true
in mod_rewrite or in an <If> block.
The https://tools.ietf.org/html/rfc7231#section-7.1.4
section seems to disallow this use case:
"The "Vary" header field in a response describes "
"what parts of a request message, "
"aside from the method, Host header field, [...]"
I had a chat with the folks in #traffic-server and
they don't see much point in having a Vary: Host header,
plus it was reported that Varnish doesn't like it very
much (namely it does not cache the response when
it sees the header, links of the report in the PR).
I don't see much value in this behavior of httpd so
I am inclined to remove this response header value,
but I'd be glad to get a more experienced opinion.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1808746 13f79535-47bb-0310-9956-ffa450edef68
*) core: %{DOCUMENT_URI} used in nested SSI expressions should point to the
URI originally requsted by the user, not the nested documents URI. This
restores the behavior of this variable to match the "legacy" SSI parser.
PR60624.
Submitted By [Hank Ibell <hwibell gmail.com>]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1780095 13f79535-47bb-0310-9956-ffa450edef68
including the scoreboard, expression and rewrite engines, setenvif,
authz_host, access_compat, custom logging, ssl and REMOTE_HOST variables.
PR55348 [William Rowe]
This is the complete change set which applies cleanly to 2.4.x as well,
the server/scoreboard.c will follow, which does not apply due to drift.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1729930 13f79535-47bb-0310-9956-ffa450edef68
case by using iteration instead of recursion.
We have a relatively small recursion limit of
about 10 operations. This is a compilation
limit (a define). It can be hit if many expr
vars or function calls are concatenated.
The new optimization is very similar to the
existing one, which optimizes consecutive
concatenations in node2 of the tree. The new
one optimizes consecutive concatenations in
node 1.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1657685 13f79535-47bb-0310-9956-ffa450edef68
No change in generated code because MODULE_MAGIC_NUMBER is defined as:
#define MODULE_MAGIC_NUMBER MODULE_MAGIC_NUMBER_MAJOR
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1611871 13f79535-47bb-0310-9956-ffa450edef68
distinguished names based on expressions to be escaped correctly to
guard against LDAP injection.
Note: this requires at least APR v1.6.0 or above for the apr_escape API.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1589986 13f79535-47bb-0310-9956-ffa450edef68
modules/debugging/mod_firehose.c: Make some internal functions static
(to do: logs_cleanup() is unused)
modules/filters/mod_charset_lite.c: Remove dead assignments
modules/filters/mod_include.c: likewise
modules/metadata/mod_usertrack.c: likewise
modules/proxy/mod_proxy_ftp.c: likewise
modules/ssl/ssl_engine_pphrase.c: likewise
modules/proxy/mod_proxy_balancer.c: likewise;
Remove NULL check that can never happen
modules/proxy/proxy_util.c: Axe NULL-check that can never happen and if it
would, it would just mask another bug
os/unix/unixd.c: likewise
modules/http/http_filters.c: Remove sub-condition that is always true
modules/lua/mod_lua.c: Add default cases to switch statements
modules/generators/mod_autoindex.c: Unsigned value can never be < 0
server/util_expr_eval.c: Fix compiler warnings with VC and on OS2
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1220493 13f79535-47bb-0310-9956-ffa450edef68
Remove some log message tags from ap_log_* calls that log lots of
different error messages, in particular the config parsing errors.
Not sure how we should handle those.
ssl_util.c: Downgrade some dynamic locking messages from level DEBUG
to TRACE1-3
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1210252 13f79535-47bb-0310-9956-ffa450edef68
