In ap_expr_parse(), ap_expr_yylex_init() will return 1 on failure,
and ctx.scanner will remain NULL. However the return value of
ap_expr_yylex_init() is not checked, and there is a dereference of
ctx.scanner in following function ap_expr_yyset_extra(),
which may lead to NULL pointer dereference.
Fix this bug by adding return value check of ap_expr_yylex_init.
Submitted by: Zhou Qingyang <zhou1615@umn.edu>
Github: closes#308
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1908772 13f79535-47bb-0310-9956-ffa450edef68
called from within ap_varbuf_strmemcat().
Moreover, 2nd parameter should be the minimum total new length, not
the amount of the growth. So this call is likely to be a no-op.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1898286 13f79535-47bb-0310-9956-ffa450edef68
* leaving mod_nw_ssl and mod_ssl itself untouched
* removing mod_ssl.h includes where no longer necessary
* some modules might skip post_config hooks, but those were left in, even when empty now.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1887364 13f79535-47bb-0310-9956-ffa450edef68
Depending on where the expression is evaluated, a request_rec might not be
available, so allow to specify only a conn_rec or a server_rec (at least) in
the passed in ap_expr_eval_ctx_t.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1877550 13f79535-47bb-0310-9956-ffa450edef68
util_expr_eval.c: In function ‘ap_expr_eval_re_backref’:
util_expr_eval.c:265:63: error: comparison between pointer and zero character constant [-Werror=pointer-compare]
if (!ctx->re_pmatch || !ctx->re_source || *ctx->re_source == '\0' ||
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1812307 13f79535-47bb-0310-9956-ffa450edef68
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
