<li><img alt="" src="../images/down.gif" /> <a href="#forcetype">ForceType</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#gprofdir">GprofDir</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#hostnamelookups">HostnameLookups</a></li>
+<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="#ifmodule"><IfModule></a></li>
<code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>. In order to prevent confusion, numbered
(unnamed) backreferences are ignored. Use named groups instead.</p>
-<pre class="prettyprint lang-config"><DirectoryMatch "^/var/www/combined/(?<sitename>[^/]+)">
+
<pre class="prettyprint lang-config"><DirectoryMatch "^/var/www/combined/(?<sitename>[^/]+)">
Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
</DirectoryMatch></pre>
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Directory that forms the main document tree visible
from the web</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>DocumentRoot <var>directory-path</var></code></td></tr>
-<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>DocumentRoot /usr/local/apache/htdocs</code></td></tr>
+<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>DocumentRoot "/usr/local/apache/htdocs"</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>
<p>This would result in error messages such as:</p>
-
<div class="example"><p><code>
+ <div class="example"><p><code>
[Thu May 12 08:28:57.652118 2011] [core:error] [pid 8777:tid 4326490112] [client ::1:58619] File does not exist: /usr/local/apache2/htdocs/favicon.ico
</code></p></div>
does. However, it accepts a <a class="glossarylink" href="../glossary.html#regex" title="see glossary">regular
expression</a>. For example:</p>
-<pre class="prettyprint lang-config"><FilesMatch ".+\.(gif|jpe?g|png)$">
+
<pre class="prettyprint lang-config"><FilesMatch ".+\.(gif|jpe?g|png)$">
# ...
</FilesMatch></pre>
<code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>. In order to prevent confusion, numbered
(unnamed) backreferences are ignored. Use named groups instead.</p>
-<pre class="prettyprint lang-config"><FilesMatch "^(?<sitename>[^/]+)">
+
<pre class="prettyprint lang-config"><FilesMatch "^(?<sitename>[^/]+)">
require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
</FilesMatch></pre>
directives</a>, a hostname lookup will be performed regardless of
the setting of <code>HostnameLookups</code>.</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="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#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>
+<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>2.2.32 or 2.4.24 and later</td></tr>
+</table>
+ <p>This directive changes the rules applied to the HTTP Request Line
+ (<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,
+ 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>
<code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>. In order to prevent confusion, numbered
(unnamed) backreferences are ignored. Use named groups instead.</p>
-<pre class="prettyprint lang-config"><LocationMatch "^/combined/(?<sitename>[^/]+)">
+
<pre class="prettyprint lang-config"><LocationMatch "^/combined/(?<sitename>[^/]+)">
require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
</LocationMatch></pre>
<p>Normally, if multiple <code class="directive">Options</code> could
apply to a directory, then the most specific one is used and
- others are ignored; the options are not merged. (See <a href="../sections.html#mergin">how sections are merged</a>.)
+ others are ignored; the options are not merged. (See <a href="../sections.html#merging">how sections are merged</a>.)
However if <em>all</em> the options on the
<code class="directive">Options</code> directive are preceded by a
<code>+</code> or <code>-</code> symbol, the options are
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="QualifyRedirectURL" id="QualifyRedirectURL">QualifyRedirectURL</a> <a name="qualifyredirecturl" id="qualifyredirecturl">Directive</a></h2>
<table class="directive">
-<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Controls whether the REDIRECT_URL environment variable is
+<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Controls whether the REDIRECT_URL environment variable is
fully qualified</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>QualifyRedirectURL ON|OFF</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>QualifyRedirectURL OFF</code></td></tr>
<p>Finally, for testing and diagnostic purposes only, request
bodies may be allowed using the non-compliant <code>TraceEnable
extended</code> directive. The core (as an origin server) will
- restrict the request body to 64k (plus 8k for chunk headers if
+ restrict the request body to 64Kb (plus 8Kb for chunk headers if
<code>Transfer-Encoding: chunked</code> is used). The core will
reflect the full headers and all chunk headers with the response
- body. As a proxy server, the request body is not restricted to 64k.</p>
+ body. As a proxy server, the request body is not restricted to 64Kb.</p>
<div class="note"><h3>Note</h3>
- <p>Despite claims to the contrary, <code>TRACE</code> is not
- a security vulnerability, and there is no viable reason for
- it to be disabled. Doing so necessarily makes your server
- noncompliant.</p>
+
+ <p>Despite claims to the contrary, enabling the <code>TRACE</code>
+ method does not expose any security vulnerability in Apache httpd.
+ The <code>TRACE</code> method is defined by the HTTP/1.1
+ specification and implementations are expected to support it.</p>
+
</div>
</div>
projects / apache / blobdiff