From b1169b4e240b3318fa7feb2e9fac0170b14ea0b5 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Andr=C3=A9=20Malo?= Date: Thu, 28 Aug 2003 15:37:17 +0000 Subject: [PATCH] add information about the == operator, && / || priorities and expression optimization/debugging git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@101124 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/mod/mod_include.html.en | 38 ++++++++++++++++++++++++++--- docs/manual/mod/mod_include.xml | 38 ++++++++++++++++++++++++++--- 2 files changed, 68 insertions(+), 8 deletions(-) diff --git a/docs/manual/mod/mod_include.html.en b/docs/manual/mod/mod_include.html.en index cfa8e1c41b..5e0fde9454 100644 --- a/docs/manual/mod/mod_include.html.en +++ b/docs/manual/mod/mod_include.html.en @@ -507,6 +507,7 @@
true if string is not empty
string1 = string2
+ string1 == string2
string1 != string2

Compare string1 with string2. If @@ -514,11 +515,12 @@ 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.

+ 5. Note that == is just an alias for = + and behaves exactly the same way.

-

If you are matching positive (=), you can capture - grouped parts of the regular expression. The captured parts are - stored in the special variables $1 .. +

If you are matching positive (= or ==), you + can capture grouped parts of the regular expression. The captured parts + are stored in the special variables $1 .. $9.

Example

@@ -566,6 +568,10 @@ <!--#if expr="($a = test1) && ($b = test2)" -->

+

The boolean operators && and || + share the same priority. So if you want to bind such an operator more + tightly, you should use parentheses.

+

Anything that's not recognized as a variable or an operator is treated as a string. Strings can also be quoted: 'string'. Unquoted strings can't contain whitespace @@ -578,6 +584,30 @@ and

'string1    string2' results in string1    string2.

+ +

Optimization of Boolean Expressions

+

If the expressions become more complex and slow down processing + significantly, you can try to optimize them according to the + evaluation rules:

+
    +
  • Expressions are evaluated from left to right
    • +
  • Binary boolean operators (&& and ||) + are short circuited whereever possible. In conclusion with the rule + above that means, mod_include evaluates at first + the left expression. If the left result if sufficient to determine + the end result, processing stops here. Otherwise it evaluates the + right side and computes the end result from both left and right + results.
    • +
  • Short circuit evaluation is turned off as long as there are regular + expressions to deal with. These must be evaluated to fill in the + backreference variables ($1 .. $9).
    • +
+

If you want to look how a particular expression is handled, you can + recompile mod_include using the + -DDEBUG_INCLUDE compiler option. This inserts for every + parsed expression tokenizer information, the parse tree and how it is + evaluated into the output sent to the client.

+
top

SSIEndTag Directive

diff --git a/docs/manual/mod/mod_include.xml b/docs/manual/mod/mod_include.xml index becbc262dc..66141d64b7 100644 --- a/docs/manual/mod/mod_include.xml +++ b/docs/manual/mod/mod_include.xml @@ -474,6 +474,7 @@
true if string is not empty
string1 = string2
+ string1 == string2
string1 != string2

Compare string1 with string2. If @@ -481,11 +482,12 @@ 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.

+ 5. Note that == is just an alias for = + and behaves exactly the same way.

-

If you are matching positive (=), you can capture - grouped parts of the regular expression. The captured parts are - stored in the special variables $1 .. +

If you are matching positive (= or ==), you + can capture grouped parts of the regular expression. The captured parts + are stored in the special variables $1 .. $9.

Example @@ -533,6 +535,10 @@ <!--#if expr="($a = test1) && ($b = test2)" --> +

The boolean operators && and || + share the same priority. So if you want to bind such an operator more + tightly, you should use parentheses.

+

Anything that's not recognized as a variable or an operator is treated as a string. Strings can also be quoted: 'string'. Unquoted strings can't contain whitespace @@ -551,6 +557,30 @@ >string2' results in string1    string2.

+ + Optimization of Boolean Expressions +

If the expressions become more complex and slow down processing + significantly, you can try to optimize them according to the + evaluation rules:

+
    +
  • Expressions are evaluated from left to right
    • +
  • Binary boolean operators (&& and ||) + are short circuited whereever possible. In conclusion with the rule + above that means, mod_include evaluates at first + the left expression. If the left result if sufficient to determine + the end result, processing stops here. Otherwise it evaluates the + right side and computes the end result from both left and right + results.
    • +
  • Short circuit evaluation is turned off as long as there are regular + expressions to deal with. These must be evaluated to fill in the + backreference variables ($1 .. $9).
    • +
+

If you want to look how a particular expression is handled, you can + recompile mod_include using the + -DDEBUG_INCLUDE compiler option. This inserts for every + parsed expression tokenizer information, the parse tree and how it is + evaluated into the output sent to the client.

+ -- 2.50.1