<usage>
<p><directive type="section">LimitExcept</directive> and
- <code></LimitExcept></code> are used to enclose a group of
- access control directives which will then apply to any HTTP access
- method <strong>not</strong> listed in the arguments; i.e., it is
- the opposite of a <directive type="section"
+ <code></LimitExcept></code> are used to enclose
+ a group of access control directives which will then apply to any
+ HTTP access method <strong>not</strong> listed in the arguments;
+ i.e., it is the opposite of a <directive type="section"
module="core">Limit</directive> section and can be used to control
both standard and nonstandard/unrecognized methods. See the
documentation for <directive module="core"
type="section">Limit</directive> for more details.</p>
+
+ <p>For example:</p>
+
+ <example>
+ <LimitExcept POST GET><br />
+ Require valid-user<br />
+ <LimitExcept>
+ </example>
+
</usage>
</directivesynopsis>
control over abnormal client request behavior, which may be
useful for avoiding some forms of denial-of-service
attacks.</p>
+
+ <p>If, for example, you are permitting file upload to a particular
+ location, and wich to limit the size of the uploaded file to 100K,
+ you might use the following directive:</p>
+
+ <example>
+ LimitRequestBody 102400
+ </example>
+
</usage>
</directivesynopsis>
The value should be increased if normal clients see an error
response from the server that indicates too many fields were
sent in the request.</p>
+
+ <p>For example:</p>
+
+ <example>
+ LimitRequestFields 50
+ </example>
+
</usage>
</directivesynopsis>
<p>This directive gives the server administrator greater
control over abnormal client request behavior, which may be
- useful for avoiding some forms of denial-of-service attacks.
- Under normal conditions, the value should not be changed from
- the default.</p>
+ useful for avoiding some forms of denial-of-service attacks.</p>
+
+ <p>For example:</p>
+
+ <example>
+ LimitRequestFieldSize 16380
+ </example>
+
+ <note>Under normal conditions, the value should not be changed from
+ the default.</note>
+
</usage>
</directivesynopsis>
<p>This directive gives the server administrator greater
control over abnormal client request behavior, which may be
- useful for avoiding some forms of denial-of-service attacks.
- Under normal conditions, the value should not be changed from
- the default.</p>
+ useful for avoiding some forms of denial-of-service attacks.</p>
+
+ <p>For example:</p>
+
+ <example>
+ LimitRequestLine 16380
+ </example>
+
+ <note>Under normal conditions, the value should not be changed from
+ the default.</note>
</usage>
</directivesynopsis>
<usage>
<p>Limit (in bytes) on maximum size of an XML-based request
body. A value of <code>0</code> will disable any checking.</p>
+
+ <p>Example:</p>
+
+ <example>
+ LimitXMLRequestBody 0
+ </example>
+
</usage>
</directivesynopsis>
<description>Applies the enclosed directives only to matching
URLs</description>
<syntax><Location
- <em>URL-path</em>|<em>URL</em>> ... </Location></syntax>
+ URL-path|URL> ... </Location></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<em>level</em>s are available, in order of decreasing
significance:</p>
- <table>
+ <table border="1">
<tr>
<th><strong>Level</strong> </th>
<th><strong>Description</strong> </th>
- </tr>
-
- <tr>
- <th>
- </th>
<th><strong>Example</strong> </th>
</tr>
<td><code>emerg</code> </td>
<td>Emergencies - system is unusable.</td>
- </tr>
-
- <tr>
- <td>
- </td>
<td>"Child cannot open lock file. Exiting"</td>
</tr>
<td><code>alert</code> </td>
<td>Action must be taken immediately.</td>
- </tr>
-
- <tr>
- <td>
- </td>
<td>"getpwuid: couldn't determine user name from uid"</td>
</tr>
<td><code>crit</code> </td>
<td>Critical Conditions.</td>
- </tr>
-
- <tr>
- <td>
- </td>
<td>"socket: Failed to get a socket, exiting child"</td>
</tr>
<td><code>error</code> </td>
<td>Error conditions.</td>
- </tr>
-
- <tr>
- <td>
- </td>
<td>"Premature end of script headers"</td>
</tr>
<td><code>warn</code> </td>
<td>Warning conditions.</td>
- </tr>
-
- <tr>
- <td>
- </td>
<td>"child process 1234 did not exit, sending another
SIGHUP"</td>
<td><code>notice</code> </td>
<td>Normal but significant condition.</td>
- </tr>
-
- <tr>
- <td>
- </td>
<td>"httpd: caught SIGBUS, attempting to dump core in
..."</td>
<td><code>info</code> </td>
<td>Informational.</td>
- </tr>
-
- <tr>
- <td>
- </td>
<td>"Server seems busy, (you may need to increase
StartServers, or Min/MaxSpareServers)..."</td>
<td><code>debug</code> </td>
<td>Debug-level messages</td>
- </tr>
-
- <tr>
- <td>
- </td>
<td>"Opening config file ..."</td>
</tr>
<p>Using a level of at least <code>crit</code> is
recommended.</p>
+
+ <p>For example:</p>
+
+ <example>LogLevel notice</example>
+
</usage>
</directivesynopsis>
set to "<code>0</code>", unlimited requests will be allowed. We
recommend that this setting be kept to a high value for maximum
server performance.</p>
+
+ <p>For example:</p>
+
+ <example>MaxKeepAliveRequests 500</example>
</usage>
</directivesynopsis>
<example>NameVirtualHost [fe80::a00:20ff:fea7:ccea]:8080</example>
+<seealso>See also: <a href="../vhosts/">Virtual Hosts
+documentation</a></seealso>
+
</usage>
</directivesynopsis>
valid username and password. This can be used to password restrict
an area, but to let clients from particular addresses in without
prompting for a password.</p>
+
+ <p>For example, if you wanted to let people on your network have
+ unrestricted access to a portion of your website, but require that
+ people outside of your network provide a password, you could use a
+ configuration similar to the following:</p>
+
+ <example>
+ Require valid-user<br />
+ Allow from 192.168.1<br />
+ Satisfy any
+ </example>
+
</usage>
+ <seealso><directive module="mod_access">Allow</directive></seealso>
+ <seealso><directive module="core">Require</directive></seealso>
</directivesynopsis>
<directivesynopsis>
request is received</seealso>
</directivesynopsis>
-</modulesynopsis>
\ No newline at end of file
+</modulesynopsis>