From: William A. Rowe Jr <wrowe@apache.org>
Date: Mon, 29 Aug 2016 17:30:53 +0000 (+0000)
Subject: Clarify documentation based on concensus decisions discussed on dev@
X-Git-Tag: 2.5.0-alpha~1185
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=9454686cdef5b16ad6f13d407c77a440e3e62bff;p=apache

Clarify documentation based on concensus decisions discussed on dev@
and reflecting the current implementation.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1758265 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/docs/manual/mod/core.xml b/docs/manual/mod/core.xml
index eb9d5bea89..3ebd81da27 100644
--- a/docs/manual/mod/core.xml
+++ b/docs/manual/mod/core.xml
@@ -1253,10 +1253,8 @@ EnableSendfile On
 <name>HttpProtocolOptions</name>
 <description>Modify restrictions on HTTP Request Messages</description>
 <syntax>HttpProtocolOptions [Strict|Unsafe] [StrictURL|UnsafeURL]
- [StrictWhitespace|UnsafeWhitespace] [RegisteredMethods|LenientMethods]
- [Allow0.9|Require1.0]</syntax>
-<default>HttpProtocolOptions Strict StrictURL StrictWhitespace 
-LenientMethods Allow0.9</default>
+ [RegisteredMethods|LenientMethods] [Allow0.9|Require1.0]</syntax>
+<default>HttpProtocolOptions Strict StrictURL LenientMethods Allow0.9</default>
 <contextlist><context>server config</context>
 <context>virtual host</context></contextlist>
 <compatibility>2.2.32 or 2.4.24 and later</compatibility>
@@ -1281,9 +1279,14 @@ LenientMethods Allow0.9</default>
       >RFC 7230 &sect;9.4 Request Splitting</a> and
     <a href="https://tools.ietf.org/html/rfc7230#section-9.5"
       >&sect;9.5 Response Smuggling</a> call out only two of the potential
-    risks of accepting non-conformant request messages. As of the introduction
-    of this directive, all grammer rules of the specification are enforced in
-    the default <code>Strict</code> operating mode.</p>
+    risks of accepting non-conformant request messages, while
+    <p><a href="https://tools.ietf.org/html/rfc7230#section-3.5"
+         >RFC 7230 &sect;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 &sect;2.2 and 2.3</a> define "Reserved Characters" and
@@ -1293,21 +1296,9 @@ LenientMethods Allow0.9</default>
     containing invalid characters. This rule can be relaxed with the
     <code>UnsafeURI</code> option to support badly written user-agents.</p>
     
-    <p><a href="https://tools.ietf.org/html/rfc7230#section-3.5"
-         >RFC 7230 &sect;3.5</a> "Message Parsing Robustness" permits, and
-    identifies potential risks of parsing messages containing non-space
-    character whitespace. While the spec defines that exactly one space
-    seperates the URI from the method, and the protocol from the URI, and
-    only space and horizontal tab characters are allowed in request header
-    field contents, the Apache HTTP Server was traditionally lenient in
-    accepting other whitespace. The default <code>StrictWhitespace</code>
-    option will now reject non-conforming requests. The administrator may
-    toggle the <code>UnsafeWhitespace</code> option to continue to honor
-    non-conforming requests, with considerable risk of proxy interactions.</p>
-
-    <p>Users are strongly cautioned against toggling the <code>Unsafe</code>,
-    <code>UnsafeURI</code> or <code>UnsafeWhitespace</code> modes of operation
-    particularly on outward-facing, publicly accessible server deployments.
+    <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