diff --git a/doc/configuration.txt b/doc/configuration.txt
index 4a5a5fffc..1ed37805c 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -8841,35 +8841,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.
@@ -8889,17 +8907,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