<li><img alt="" src="../images/down.gif" /> <a href="#httpprotocoloptions">HttpProtocolOptions</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#if"><If></a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#ifdefine"><IfDefine></a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#iffile"><IfFile></a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#ifmodule"><IfModule></a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#include">Include</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#includeoptional">IncludeOptional</a></li>
send the response without a Content-Type header field and the
recipient may attempt to guess the media type.</p>
+<h3>See also</h3>
+<ul>
+<li><code class="directive"><a href="#undefine">UnDefine</a></code></li>
+<li><code class="directive"><a href="#ifdefine">IfDefine</a></code></li>
+</ul>
</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="Define" id="Define">Define</a> <a name="define" id="define">Directive</a></h2>
<p>While this directive is supported in virtual host context,
the changes it makes are visible to any later configuration
- directives, beyond any enclosing virtual host</p>
+ directives, beyond any enclosing virtual host.</p>
</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<p>matches directories in <code>/www/</code> (or any subdirectory thereof)
that consist of three numbers.</p>
- <div class="note"><h3>Compatability</h3>
+ <div class="note"><h3>Compatibility</h3>
Prior to 2.3.9, this directive implicitly applied to sub-directories
(like <code class="directive"><a href="#directory"><Directory></a></code>) and
could not match the end of line symbol ($). In 2.3.9 and later,
<div class="directive-section"><h2><a name="ErrorLog" id="ErrorLog">ErrorLog</a> <a name="errorlog" id="errorlog">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Location where the server will log errors</td></tr>
-<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code> ErrorLog <var>file-path</var>|syslog[:<var>facility</var>]</code></td></tr>
+<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code> ErrorLog <var>file-path</var>|syslog[:[<var>facility</var>][:<var>tag</var>]]</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows and OS/2)</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Core</td></tr>
syntax where <var>facility</var> can be one of the names usually documented in
syslog(1). The facility is effectively global, and if it is changed
in individual virtual hosts, the final facility specified affects the
- entire server.</p>
+ entire server. Same rules apply for the syslog tag, which by default
+ uses the Apache binary name, <code>httpd</code> in most cases. You can
+ also override this by using the <code>syslog::<var>tag</var></code>
+ syntax.</p>
- <pre class="prettyprint lang-config">ErrorLog syslog:user</pre>
+ <pre class="prettyprint lang-config">ErrorLog syslog:user
+ErrorLog syslog:user:httpd.srv1
+ErrorLog syslog::httpd.srv2</pre>
<p>Additional modules can provide their own ErrorLog providers. The syntax
<div class="directive-section"><h2><a name="HttpProtocolOptions" id="HttpProtocolOptions">HttpProtocolOptions</a> <a name="httpprotocoloptions" id="httpprotocoloptions">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Modify restrictions on HTTP Request Messages</td></tr>
-<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>HttpProtocolOptions [Strict|Unsafe] [StrictURL|UnsafeURL]
- [RegisteredMethods|LenientMethods] [Allow0.9|Require1.0]</code></td></tr>
-<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>HttpProtocolOptions Strict StrictURL LenientMethods Allow0.9</code></td></tr>
+<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>HttpProtocolOptions [Strict|Unsafe] [RegisteredMethods|LenientMethods]
+ [Allow0.9|Require1.0]</code></td></tr>
+<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>HttpProtocolOptions Strict LenientMethods Allow0.9</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Core</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>core</td></tr>
(<a href="https://tools.ietf.org/html/rfc7230#section-3.1.1">RFC 7230 §3.1.1</a>) and the HTTP Request Header Fields
(<a href="https://tools.ietf.org/html/rfc7230#section-3.2">RFC 7230 §3.2</a>), which are now applied by default or using
the <code>Strict</code> option. Due to legacy modules, applications or
- custom user-agents which must be deperecated, <code>Unsafe</code>
- and <code>UnsafeURL</code> options have been added to revert to the legacy
- behaviors. These rules are applied prior to request processing, so must be
- configured at the global or default (first) matching virtual host section,
- by IP/port interface and not by name, to be honored.</p>
-
- <p>Prior to the introduction of this directive, the Apache HTTP Server
- request message parsers were tolerant of a number of forms of input
- which did not conform to the protocol.
- <a href="https://tools.ietf.org/html/rfc7230#section-9.4">RFC 7230 §9.4 Request Splitting</a> and
- <a href="https://tools.ietf.org/html/rfc7230#section-9.5">§9.5 Response Smuggling</a> call out only two of the potential
- risks of accepting non-conformant request messages, while
- <a href="https://tools.ietf.org/html/rfc7230#section-3.5">RFC 7230 §3.5</a> "Message Parsing Robustness" identify the
- risks of accepting obscure whitespace and request message formatting.
- As of the introduction of this directive, all grammer rules of the
- specification are enforced in the default <code>Strict</code> operating
- mode, and the strict whitespace suggested by section 3.5 is enforced
- and cannot be relaxed.</p>
-
- <p><a href="https://tools.ietf.org/html/rfc3986#section-2.2">RFC 3986 §2.2 and 2.3</a> define "Reserved Characters" and
- "Unreserved Characters". All other character octets are required to
- be %XX encoded under this spec, and RFC7230 defers to these requirements.
- By default the <code>StrictURI</code> option will reject all requests
- containing invalid characters. This rule can be relaxed with the
- <code>UnsafeURI</code> option to support badly written user-agents.</p>
-
- <p>Users are strongly cautioned against toggling the <code>Unsafe</code>
- or <code>UnsafeURI</code> modes of operation, particularly on
- outward-facing, publicly accessible server deployments.
- If an interface is required for faulty monitoring or other custom service
- consumers running on an intranet, users should toggle only those Unsafe
- options which are necessary, and only on a specific virtual host configured
- to service only their internal private network.</p>
-
- <p>Reviewing the messages logged to the <code class="directive">ErrorLog</code>,
- configured with <code class="directive">LogLevel</code> <code>debug</code> level,
+ custom user-agents which must be deprecated the <code>Unsafe</code>
+ option has been added to revert to the legacy behaviors.</p>
+
+ <p>These rules are applied prior to request processing,
+ so must be configured at the global or default (first) matching
+ virtual host section, by IP/port interface (and not by name)
+ to be honored.</p>
+
+ <p>The directive accepts three parameters from the following list
+ of choices, applying the default to the ones not specified:</p>
+
+ <dl>
+ <dt>Strict|Unsafe</dt>
+ <dd>
+ <p>Prior to the introduction of this directive, the Apache HTTP Server
+ request message parsers were tolerant of a number of forms of input
+ which did not conform to the protocol.
+ <a href="https://tools.ietf.org/html/rfc7230#section-9.4">RFC 7230 §9.4 Request Splitting</a> and
+ <a href="https://tools.ietf.org/html/rfc7230#section-9.5">§9.5 Response Smuggling</a> call out only two of the potential
+ risks of accepting non-conformant request messages, while
+ <a href="https://tools.ietf.org/html/rfc7230#section-3.5">RFC 7230 §3.5</a> "Message Parsing Robustness" identify the
+ risks of accepting obscure whitespace and request message formatting.
+ As of the introduction of this directive, all grammar rules of the
+ specification are enforced in the default <code>Strict</code> operating
+ mode, and the strict whitespace suggested by section 3.5 is enforced
+ and cannot be relaxed.</p>
+
+ <div class="warning"><h3>Security risks of Unsafe</h3>
+ <p>Users are strongly cautioned against toggling the <code>Unsafe</code>
+ mode of operation, particularly on outward-facing, publicly accessible
+ server deployments. If an interface is required for faulty monitoring
+ or other custom service consumers running on an intranet, users should
+ toggle the Unsafe option only on a specific virtual host configured
+ to service their internal private network.</p>
+ </div>
+
+ <div class="example"><h3>Example of a request leading to HTTP 400 with Strict mode</h3><p><code>
+
+ # Missing CRLF<br />
+ GET / HTTP/1.0\n\n
+ </code></p></div>
+ <div class="warning"><h3>Command line tools and CRLF</h3>
+ <p>Some tools need to be forced to use CRLF, otherwise httpd will return
+ a HTTP 400 response like described in the above use case. For example,
+ the <strong>OpenSSL s_client needs the -crlf parameter to work
+ properly</strong>.</p>
+ <p>The <code class="directive"><a href="../mod/mod_dumpio.html#dumpioinput">DumpIOInput</a></code> directive
+ can help while reviewing the HTTP request to identify issues like the
+ absence of CRLF.</p>
+ </div>
+ </dd>
+ <dt>RegisteredMethods|LenientMethods</dt>
+ <dd>
+ <p><a href="https://tools.ietf.org/html/rfc7231#section-4.1">RFC 7231 §4.1</a> "Request Methods" "Overview" requires that
+ origin servers shall respond with a HTTP 501 status code when an
+ unsupported method is encountered in the request line.
+ This already happens when the <code>LenientMethods</code> option is used,
+ but administrators may wish to toggle the <code>RegisteredMethods</code>
+ option and register any non-standard methods using the
+ <code class="directive"><a href="#registerhttpmethod">RegisterHttpMethod</a></code>
+ directive, particularly if the <code>Unsafe</code>
+ option has been toggled.</p>
+
+ <div class="warning"><h3>Forward Proxy compatibility</h3>
+ <p>The <code>RegisteredMethods</code> option should <strong>not</strong>
+ be toggled for forward proxy hosts, as the methods supported by the
+ origin servers are unknown to the proxy server.</p>
+ </div>
+
+ <div class="example"><h3>Example of a request leading to HTTP 501 with LenientMethods mode</h3><p><code>
+
+ # Unknown HTTP method<br />
+ WOW / HTTP/1.0\r\n\r\n<br /><br />
+ # Lowercase HTTP method<br />
+ get / HTTP/1.0\r\n\r\n<br />
+ </code></p></div>
+ </dd>
+ <dt>Allow0.9|Require1.0</dt>
+ <dd>
+ <p><a href="https://tools.ietf.org/html/rfc2616#section-19.6">RFC 2616 §19.6</a> "Compatibility With Previous Versions" had
+ encouraged HTTP servers to support legacy HTTP/0.9 requests. RFC 7230
+ supersedes this with "The expectation to support HTTP/0.9 requests has
+ been removed" and offers additional comments in
+ <a href="https://tools.ietf.org/html/rfc7230#appendix-A">RFC 7230 Appendix A</a>. The <code>Require1.0</code> option allows
+ the user to remove support of the default <code>Allow0.9</code> option's
+ behavior.</p>
+
+ <div class="example"><h3>Example of a request leading to HTTP 400 with Require1.0 mode</h3><p><code>
+
+ # Unsupported HTTP version<br />
+ GET /\r\n\r\n
+ </code></p></div>
+ </dd>
+ </dl>
+ <p>Reviewing the messages logged to the
+ <code class="directive"><a href="#errorlog">ErrorLog</a></code>, configured with
+ <code class="directive"><a href="#loglevel">LogLevel</a></code> <code>debug</code> level,
can help identify such faulty requests along with their origin.
Users should pay particular attention to the 400 responses in the access
log for invalid requests which were unexpectedly rejected.</p>
- <p><a href="https://tools.ietf.org/html/rfc7231#section-4.1">RFC 7231 §4.1</a> "Request Methods" "Overview" requires that
- origin servers shall respond with an error when an unsupported method
- is encountered in the request line. This already happens when the
- <code>LenientMethods</code> option is used, but administrators may wish
- to toggle the <code>RegisteredMethods</code> option and register any
- non-standard methods using the <code class="directive">RegisterHttpMethod</code>
- directive, particularly if the <code>Unsafe</code> option has been toggled.
- The <code>RegisteredMethods</code> option should <strong>not</strong>
- be toggled for forward proxy hosts, as the methods supported by the
- origin servers are unknown to the proxy server.</p>
-
- <p><a href="https://tools.ietf.org/html/rfc2616#section-19.6">RFC 2616 §19.6</a> "Compatibility With Previous Versions" had
- encouraged HTTP servers to support legacy HTTP/0.9 requests. RFC 7230
- superceeds this with "The expectation to support HTTP/0.9 requests has
- been removed" and offers additional comments in
- <a href="https://tools.ietf.org/html/rfc7230#appendix-A">RFC 7230 Appendix A</a>. The <code>Require1.0</code> option allows
- the user to remove support of the default <code>Allow0.9</code> option's
- behavior.</p>
-
</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="If" id="If"><If></a> <a name="if" id="if">Directive</a></h2>
</IfDefine></pre>
+</div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="directive-section"><h2><a name="IfFile" id="IfFile"><IfFile></a> <a name="iffile" id="iffile">Directive</a></h2>
+<table class="directive">
+<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Encloses directives that will be processed only
+if file exists at startup</td></tr>
+<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code><IfFile [!]<var>parameter-name</var>> ...
+ </IfFile></code></td></tr>
+<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host, directory, .htaccess</td></tr>
+<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Core</td></tr>
+<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>core</td></tr>
+</table>
+ <p>The <code><IfFile <var>filename</var>>...</IfFile>
+ </code> section is used to mark directives that are conditional on
+ the existence of a file on disk. The directives within an
+ <code class="directive"><IfFile></code> section are only
+ processed if the <var>filename</var> exists. If <var> filename</var>
+ doesn't exist, everything between the start and end markers is
+ ignored. <var>filename</var> can be an absolute path or a path
+ relative to the server root.</p>
+
+ <p>The <var>filename</var> in the <code class="directive"><IfFile
+ ></code> section directive can take the same forms as the
+ <var>test</var> variable in the <code class="directive"><IfDefine
+ ></code> section, i.e. the test can be negated if the <code>
+ !</code> character is placed directly before <var>filename</var>.
+ </p>
+
+ <p>If a relative <var>filename</var> is supplied, the check is
+ <code class="directive">ServerRoot</code> relative. In the case where
+ this directive occurs before the <code class="directive">ServerRoot</code>,
+ the path will be checked relative to the compiled-in server root or
+ the server root passed in on the command line via the <code>-d</code>
+ parameter.</p>
+
+
</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="IfModule" id="IfModule"><IfModule></a> <a name="ifmodule" id="ifmodule">Directive</a></h2>
<p>Examples:</p>
- <pre class="prettyprint lang-config"> LogLevelOverride 192.0.2.0/24 ssl:trace6
- LogLevelOverride 192.0.2.7 ssl:trace8</pre>
+ <pre class="prettyprint lang-config"> LogLevelOverride 192.0.2.0/24 ssl:trace6
+ LogLevelOverride 192.0.2.7 ssl:trace8</pre>
<div class="note">
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Core</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>core</td></tr>
</table>
-<p>HTTP Methods that are not conforming to the relvant RFCs are normally
+<p>HTTP Methods that are not conforming to the relevant RFCs are normally
rejected by request processing in Apache HTTPD. To avoid this, modules
can register non-standard HTTP methods they support.
The <code class="directive">RegisterHttpMethod</code> allows to register such
full.</li>
<li>In <code class="module"><a href="../mod/mod_cgi.html">mod_cgi</a></code> and <code class="module"><a href="../mod/mod_cgid.html">mod_cgid</a></code>,
- the length of time to wait for output from a CGI script.</li>
+ the length of time to wait for any individual block of output
+ from a CGI script.</li>
<li>In <code class="module"><a href="../mod/mod_ext_filter.html">mod_ext_filter</a></code>, the length of time to
wait for output from a filtering process.</li>
the changes it makes are visible to any later configuration
directives, beyond any enclosing virtual host.</p>
+<h3>See also</h3>
+<ul>
+<li><code class="directive"><a href="#define">Define</a></code></li>
+<li><code class="directive"><a href="#ifdefine">IfDefine</a></code></li>
+</ul>
</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="UseCanonicalName" id="UseCanonicalName">UseCanonicalName</a> <a name="usecanonicalname" id="usecanonicalname">Directive</a></h2>
}
})(window, document);
//--><!]]></script></div><div id="footer">
-<p class="apache">Copyright 201
6 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
+<p class="apache">Copyright 201
7 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/quickreference.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div><script type="text/javascript"><!--//--><
projects / apache / blobdiff