From: Stefan Fritsch Date: Sun, 7 Nov 2010 22:53:59 +0000 (+0000) Subject: Support %{HANDLER} in ap_expr (required for mod_filter) X-Git-Tag: 2.3.9~83 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=b6aec76bc14ae045c4cddbfa87618f56ea52475b;p=apache Support %{HANDLER} in ap_expr (required for mod_filter) Update mod_filter docs git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1032413 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/expr.xml b/docs/manual/expr.xml index 56a7909564..67fd7a47b7 100644 --- a/docs/manual/expr.xml +++ b/docs/manual/expr.xml @@ -161,6 +161,8 @@ listfunction ::= listfuncname "(" word ")" CONTENT_TYPE + HANDLER + REMOTE_ADDR HTTPS diff --git a/docs/manual/mod/mod_filter.xml b/docs/manual/mod/mod_filter.xml index ab5b487279..2a9880d79d 100644 --- a/docs/manual/mod/mod_filter.xml +++ b/docs/manual/mod/mod_filter.xml @@ -118,7 +118,8 @@ headers, environment variables, or the Handler used by this request. Unlike earlier versions, mod_filter now supports complex expressions involving multiple criteria with AND / OR logic (&& / ||) - and brackets. + and brackets. The details of the expression syntax are described in + the ap_expr documentation.
Configure the Chain
The above directives build components of a smart filter chain, @@ -143,15 +144,14 @@ more versatile expression. In general, you can convert a match/dispatch pair to the two sides of an expression, using something like:

- "dispatch = match" + "dispatch = 'match'"

The Request headers, Response headers and Environment variables - are now interpreted from syntax $req{foo}, - $resp{foo} and $env{foo} respectively. - The variables $handler and $Content-Type + are now interpreted from syntax %{req:foo}, + %{resp:foo} and %{env:foo} respectively. + The variables %{HANDLER} and %{CONTENT_TYPE} are also supported.

-

Note that the match no longer supports integer comparisons - or substring matches. The latter can be replaced by regular - expression matches.

+

Note that the match no longer support substring matches. They can be + replaced by regular expression matches.

Examples @@ -160,7 +160,7 @@
A simple case of replacing AddOutputFilterByType FilterDeclare SSI
- FilterProvider SSI INCLUDES "$resp{Content-Type} = /^text\/html/"
+ FilterProvider SSI INCLUDES "%{CONTENT_TYPE} =~ m|^text/html|"
FilterChain SSI
@@ -169,7 +169,7 @@
The same as the above but dispatching on handler (classic SSI behaviour; .shtml files get processed). - FilterProvider SSI INCLUDES "Handler = server-parsed"
+ FilterProvider SSI INCLUDES "%{HANDLER} = 'server-parsed'"
FilterChain SSI
@@ -179,7 +179,7 @@ Accept-Encoding header. This filter runs with ftype CONTENT_SET. FilterDeclare gzip CONTENT_SET
- FilterProvider gzip inflate "$req{Accept-Encoding} != /gzip/"
+ FilterProvider gzip inflate "%{req:Accept-Encoding} !~ /gzip/"
FilterChain gzip
@@ -188,16 +188,16 @@
Suppose we want to downsample all web images, and have filters for GIF, JPEG and PNG. - FilterProvider unpack jpeg_unpack "$resp{Content-Type} = image/jpeg"
- FilterProvider unpack gif_unpack "$resp{Content-Type} = image/gif"
- FilterProvider unpack png_unpack "$resp{Content-Type} = image/png"
+ FilterProvider unpack jpeg_unpack "%{CONTENT_TYPE} = 'image/jpeg'"
+ FilterProvider unpack gif_unpack "%{CONTENT_TYPE} = 'image/gif'"
+ FilterProvider unpack png_unpack "%{CONTENT_TYPE} = 'image/png'"

- FilterProvider downsample downsample_filter "$resp{Content-Type} = /image\/(jpeg|gif|png)/"
+ FilterProvider downsample downsample_filter "%{CONTENT_TYPE} = m|^image/(jpeg|gif|png)|"
FilterProtocol downsample "change=yes"

- FilterProvider repack jpeg_pack "$resp{Content-Type} = image/jpeg"
- FilterProvider repack gif_pack "$resp{Content-Type} = image/gif"
- FilterProvider repack png_pack "$resp{Content-Type} = image/png"
+ FilterProvider repack jpeg_pack "%{CONTENT_TYPE} = 'image/jpeg'"
+ FilterProvider repack gif_pack "%{CONTENT_TYPE} = 'image/gif'"
+ FilterProvider repack png_pack "%{CONTENT_TYPE} = 'image/png'"
<Location /image-filter>
FilterChain unpack downsample repack
@@ -359,50 +359,8 @@ ap_register_output_filter.

-

expression can be any of the following:

-
-
string
-
true if string is not empty
- -
string1 = string2
- string1 == string2
- string1 != string2
- -

Compare string1 with string2. If - string2 has the form /string2/ - then it is treated as a regular expression. Regular expressions are - implemented by the PCRE engine and - have the same syntax as those in perl - 5. Note that == is just an alias for = - and behaves exactly the same way.

-
- -
string1 < string2
- string1 <= string2
- string1 > string2
- string1 >= string2
- -
Compare string1 with string2. Note, that - strings are compared literally (using - strcmp(3)). Therefore the string "100" is less than - "20".
- -
( expression )
-
true if expression is true
- -
! expression
-
true if expression is false
- -
expression1 && - expression2
-
true if both expression1 and - expression2 are true
- -
expression1 || - expression2
-
true if either expression1 or - expression2 is true
-
+

expression is described in the + ap_expr documentation.

diff --git a/docs/manual/upgrading.xml b/docs/manual/upgrading.xml index 15878eb4b5..1336306dfb 100644 --- a/docs/manual/upgrading.xml +++ b/docs/manual/upgrading.xml @@ -221,6 +221,11 @@ directive, review your configuration to make sure it is present in all the necessary directory contexts. +
  • mod_filter: FilterProvider syntax has changed and + now uses a boolean expression to determine if a filter is applied. +
    • + diff --git a/server/util_expr_eval.c b/server/util_expr_eval.c index 2b80e73efb..1901666fa2 100644 --- a/server/util_expr_eval.c +++ b/server/util_expr_eval.c @@ -888,6 +888,7 @@ static const char *request_var_names[] = { "AUTH_TYPE", /* 16 */ "THE_REQUEST", /* 17 */ "CONTENT_TYPE", /* 18 */ + "HANDLER", /* 19 */ NULL }; @@ -938,6 +939,8 @@ static const char *request_var_fn(ap_expr_eval_ctx *ctx, const void *data) return r->the_request; case 18: return r->content_type; + case 19: + return r->handler; default: ap_assert(0); return NULL;