You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by nd...@apache.org on 2003/08/28 17:37:17 UTC
cvs commit: httpd-2.0/docs/manual/mod mod_include.html.en mod_include.xml
nd 2003/08/28 08:37:17
Modified: docs/manual/mod mod_include.html.en mod_include.xml
Log:
add information about the == operator, && / || priorities and
expression optimization/debugging
Revision Changes Path
1.28 +34 -4 httpd-2.0/docs/manual/mod/mod_include.html.en
Index: mod_include.html.en
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_include.html.en,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- mod_include.html.en 30 Jun 2003 01:16:32 -0000 1.27
+++ mod_include.html.en 28 Aug 2003 15:37:16 -0000 1.28
@@ -507,6 +507,7 @@
<dd>true if <var>string</var> is not empty</dd>
<dt><code><var>string1</var> = <var>string2</var><br />
+ <var>string1</var> == <var>string2</var><br />
<var>string1</var> != <var>string2</var></code></dt>
<dd><p>Compare <var>string1</var> with <var>string2</var>. If
@@ -514,11 +515,12 @@
then it is treated as a regular expression. Regular expressions are
implemented by the <a href="http://www.pcre.org">PCRE</a> engine and
have the same syntax as those in <a href="http://www.perl.com">perl
- 5</a>.</p>
+ 5</a>. Note that <code>==</code> is just an alias for <code>=</code>
+ and behaves exactly the same way.</p>
- <p>If you are matching positive (<code>=</code>), you can capture
- grouped parts of the regular expression. The captured parts are
- stored in the special variables <code>$1</code> ..
+ <p>If you are matching positive (<code>=</code> or <code>==</code>), you
+ can capture grouped parts of the regular expression. The captured parts
+ are stored in the special variables <code>$1</code> ..
<code>$9</code>.</p>
<div class="example"><h3>Example</h3><p><code>
@@ -566,6 +568,10 @@
<!--#if expr="($a = test1) && ($b = test2)" -->
</code></p></div>
+ <p>The boolean operators <code>&&</code> and <code>||</code>
+ share the same priority. So if you want to bind such an operator more
+ tightly, you should use parentheses.</p>
+
<p>Anything that's not recognized as a variable or an operator
is treated as a string. Strings can also be quoted:
<code>'string'</code>. Unquoted strings can't contain whitespace
@@ -578,6 +584,30 @@
and<br />
<br />
<code>'<var>string1</var> <var>string2</var>'</code> results in <code><var>string1</var> <var>string2</var></code>.</p></div>
+
+ <div class="note"><h3>Optimization of Boolean Expressions</h3>
+ <p>If the expressions become more complex and slow down processing
+ significantly, you can try to optimize them according to the
+ evaluation rules:</p>
+ <ul>
+ <li>Expressions are evaluated from left to right</li>
+ <li>Binary boolean operators (<code>&&</code> and <code>||</code>)
+ are short circuited whereever possible. In conclusion with the rule
+ above that means, <code class="module"><a href="../mod/mod_include.html">mod_include</a></code> 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.</li>
+ <li>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 (<code>$1</code> .. <code>$9</code>).</li>
+ </ul>
+ <p>If you want to look how a particular expression is handled, you can
+ recompile <code class="module"><a href="../mod/mod_include.html">mod_include</a></code> using the
+ <code>-DDEBUG_INCLUDE</code> 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.</p>
+ </div>
</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSIEndTag" id="SSIEndTag">SSIEndTag</a> <a name="ssiendtag" id="ssiendtag">Directive</a></h2>
1.24 +34 -4 httpd-2.0/docs/manual/mod/mod_include.xml
Index: mod_include.xml
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_include.xml,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- mod_include.xml 30 Jun 2003 01:07:23 -0000 1.23
+++ mod_include.xml 28 Aug 2003 15:37:17 -0000 1.24
@@ -474,6 +474,7 @@
<dd>true if <var>string</var> is not empty</dd>
<dt><code><var>string1</var> = <var>string2</var><br />
+ <var>string1</var> == <var>string2</var><br />
<var>string1</var> != <var>string2</var></code></dt>
<dd><p>Compare <var>string1</var> with <var>string2</var>. If
@@ -481,11 +482,12 @@
then it is treated as a regular expression. Regular expressions are
implemented by the <a href="http://www.pcre.org">PCRE</a> engine and
have the same syntax as those in <a href="http://www.perl.com">perl
- 5</a>.</p>
+ 5</a>. Note that <code>==</code> is just an alias for <code>=</code>
+ and behaves exactly the same way.</p>
- <p>If you are matching positive (<code>=</code>), you can capture
- grouped parts of the regular expression. The captured parts are
- stored in the special variables <code>$1</code> ..
+ <p>If you are matching positive (<code>=</code> or <code>==</code>), you
+ can capture grouped parts of the regular expression. The captured parts
+ are stored in the special variables <code>$1</code> ..
<code>$9</code>.</p>
<example><title>Example</title>
@@ -533,6 +535,10 @@
<!--#if expr="($a = test1) && ($b = test2)" -->
</example>
+ <p>The boolean operators <code>&&</code> and <code>||</code>
+ share the same priority. So if you want to bind such an operator more
+ tightly, you should use parentheses.</p>
+
<p>Anything that's not recognized as a variable or an operator
is treated as a string. Strings can also be quoted:
<code>'string'</code>. Unquoted strings can't contain whitespace
@@ -551,6 +557,30 @@
>string2</var>'</code> results in <code><var
>string1</var> <var>string2</var></code>.</p>
</example>
+
+ <note><title>Optimization of Boolean Expressions</title>
+ <p>If the expressions become more complex and slow down processing
+ significantly, you can try to optimize them according to the
+ evaluation rules:</p>
+ <ul>
+ <li>Expressions are evaluated from left to right</li>
+ <li>Binary boolean operators (<code>&&</code> and <code>||</code>)
+ are short circuited whereever possible. In conclusion with the rule
+ above that means, <module>mod_include</module> 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.</li>
+ <li>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 (<code>$1</code> .. <code>$9</code>).</li>
+ </ul>
+ <p>If you want to look how a particular expression is handled, you can
+ recompile <module>mod_include</module> using the
+ <code>-DDEBUG_INCLUDE</code> 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.</p>
+ </note>
</section>
<directivesynopsis>