DOC: config: Explicitly list relaxing rules for accept-invalid-http-* options

Time to time, new exceptions are added in the HTTP parsing (most of time H1)
to not reject some invalid messages sent by legacy applications. But the
documentation of accept-invalid-http-request and
accept-invalid-http-response options is not pretty clear. So, now, there is
an explicit list of relaxing rules for both options.

(cherry picked from commit 0f4fad5291027a7dfc8109fbbe2acd0bac8affd0)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>

diff --git a/doc/configuration.txt b/doc/configuration.txt
index bede856..f4054cb 100644 (file)
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -8697,35 +8697,53 @@ no option accept-invalid-http-request
 
   Arguments : none
 
-  By default, HAProxy complies with RFC7230 in terms of message parsing. This
-  means that invalid characters in header names are not permitted and cause an
-  error to be returned to the client. This is the desired behavior as such
-  forbidden characters are essentially used to build attacks exploiting server
-  weaknesses, and bypass security filtering. Sometimes, a buggy browser or
-  server will emit invalid header names for whatever reason (configuration,
-  implementation) and the issue will not be immediately fixed. In such a case,
-  it is possible to relax HAProxy's header name parser to accept any character
-  even if that does not make sense, by specifying this option. Similarly, the
-  list of characters allowed to appear in a URI is well defined by RFC3986, and
-  chars 0-31, 32 (space), 34 ('"'), 60 ('<'), 62 ('>'), 92 ('\'), 94 ('^'), 96
-  ('`'), 123 ('{'), 124 ('|'), 125 ('}'), 127 (delete) and anything above are
-  not allowed at all. HAProxy always blocks a number of them (0..32, 127). The
-  remaining ones are blocked by default unless this option is enabled. This
-  option also relaxes the test on the HTTP version, it allows HTTP/0.9 requests
-  to pass through (no version specified), as well as different protocol names
-  (e.g. RTSP), and multiple digits for both the major and the minor version.
-  Finally, this option also allows incoming URLs to contain fragment references
-  ('#' after the path).
+  By default, HAProxy complies with the different HTTP RFCs in terms of message
+  parsing. This means the message parsing is quite strict and causes an error
+  to be returned to the client for malformed messages. This is the desired
+  behavior as such malformed messages are essentially used to build attacks
+  exploiting server weaknesses, and bypass security filtering. Sometimes, a
+  buggy browser will not respect these RCFs for whatever reason (configuration,
+  implementation...) and the issue will not be immediately fixed. In such case,
+  it is possible to relax HAProxy's parser to accept some invalid requests by
+  specifying this option. Most of rules concern the H1 parsing for historical
+  reason. Newer HTTP versions tends to be cleaner and applications follow more
+  stickly these protocols.
+
+  When this option is set, the following rules are observed:
+
+    * In H1 only, invalid characters, including NULL character, in header name
+      will be accepted;
+
+    * In H1 only, NULL character in header value will be accepted;
+
+    * The list of characters allowed to appear in a URI is well defined by
+      RFC3986, and chars 0-31, 32 (space), 34 ('"'), 60 ('<'), 62 ('>'), 92
+      ('\'), 94 ('^'), 96 ('`'), 123 ('{'), 124 ('|'), 125 ('}'), 127 (delete)
+      and anything above are normally not allowed. But here, in H1 only,
+      HAProxy will only block a number of them (0..32, 127);
+
+    * In H1 and H2, URLs containing fragment references ('#' after the path)
+      will be accepted;
+
+    * In H1 only, no check will be performed on the authority for CONNECT
+      requests;
+
+    * In H1 only, no check will be performed against the authority and the Host
+      header value.
+
+    * In H1 only, tests on the HTTP version will be relaxed. It will allow
+      HTTP/0.9 GET requests to pass through (no version specified), as well as
+      different protocol names (e.g. RTSP), and multiple digits for both the
+      major and the minor version.
 
   This option should never be enabled by default as it hides application bugs
   and open security breaches. It should only be deployed after a problem has
   been confirmed.
 
-  When this option is enabled, erroneous header names will still be accepted in
-  requests, but the complete request will be captured in order to permit later
-  analysis using the "show errors" request on the UNIX stats socket. Similarly,
-  requests containing invalid chars in the URI part will be logged. Doing this
-  also helps confirming that the issue has been solved.
+  When this option is enabled, invalid but accepted H1 requests will be
+  captured in order to permit later analysis using the "show errors" request on
+  the UNIX stats socket.Doing this also helps confirming that the issue has
+  been solved.
 
   If this option has been enabled in a "defaults" section, it can be disabled
   in a specific instance by prepending the "no" keyword before it.
@@ -8745,17 +8763,28 @@ no option accept-invalid-http-response
 
   Arguments : none
 
-  By default, HAProxy complies with RFC7230 in terms of message parsing. This
-  means that invalid characters in header names are not permitted and cause an
-  error to be returned to the client. This is the desired behavior as such
-  forbidden characters are essentially used to build attacks exploiting server
-  weaknesses, and bypass security filtering. Sometimes, a buggy browser or
-  server will emit invalid header names for whatever reason (configuration,
-  implementation) and the issue will not be immediately fixed. In such a case,
-  it is possible to relax HAProxy's header name parser to accept any character
-  even if that does not make sense, by specifying this option. This option also
-  relaxes the test on the HTTP version format, it allows multiple digits for
-  both the major and the minor version.
+  Similarly to "option accept-invalid-http-request", this option may be used to
+  relax parsing rules of HTTP responses. It should only be enabled for trusted
+  legacy servers to accept some invalid responses. Most of rules concern the H1
+  parsing for historical reason. Newer HTTP versions tends to be cleaner and
+  applications follow more stickly these protocols.
+
+  When this option is set, the following rules are observed:
+
+    * In H1 only, invalid characters, including NULL character, in header name
+      will be accepted;
+
+    * In H1 only, NULL character in header value will be accepted;
+
+    * In H1 only, empty values or several "chunked" value occurrences for
+      Transfer-Encoding header will be accepted;
+
+    * In H1 only, no check will be performed against the authority and the Host
+      header value.
+
+    * In H1 only, tests on the HTTP version will be relaxed. It will allow
+      different protocol names (e.g. RTSP), and multiple digits for both the
+      major and the minor version.
 
   This option should never be enabled by default as it hides application bugs
   and open security breaches. It should only be deployed after a problem has