]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
DOC: config: Add notes about errors emitted by H1 mux
authorChristopher Faulet <cfaulet@haproxy.com>
Wed, 2 Dec 2020 07:40:14 +0000 (08:40 +0100)
committerChristopher Faulet <cfaulet@haproxy.com>
Fri, 4 Dec 2020 13:41:49 +0000 (14:41 +0100)
Now, some errors are handled by the H1 multiplexer. During the headers
parsing request, there is no stream attached to the H1 mux. Thus, if an
error is reported at this stage, it is handled by the mux itself. If
possible the corresponding frontend errorfile is used, but it should be a
static message. Custom error messages are not supported. Otherwise, default
error messages are used.

In addition, the http analysis has not started yet, so http-after-response
ruleset is not evaluated and cannot alter these early responses.

doc/configuration.txt

index 9ca24361c172801aae338005acd1c38b179b54a9..81a90daf9682e84b7a9947c2f014af5f4af09fc6 100644 (file)
@@ -4927,6 +4927,10 @@ http-after-response <action> <options...> [ { if | unless } <condition> ]
   There is no limit to the number of http-after-response statements per
   instance.
 
+  Note: Errors emitted in early stage of the request parsing are handled by the
+        multiplexer at a lower level, before any http analysis. Thus no
+        http-after-response ruleset is evaluated on these errors.
+
   Example:
     http-after-response set-header Strict-Transport-Security "max-age=31536000"
     http-after-response set-header Cache-Control "no-store,no-cache,private"
@@ -5592,6 +5596,12 @@ http-error status <code> [content-type <type>]
   For this reason, the errors continue to be returned even when the process is
   chrooted, and no file change is considered while the process is running.
 
+  Note: 400/408/500 errors emitted in early stage of the request parsing are
+        handled by the multiplexer at a lower level. No custom formatting is
+        supported at this level. Thus only static error messages, defined with
+        "errorfile" directive, are supported. However, this limitation only
+        exists during the request headers parsing or between two transactions.
+
   See also : "errorfile", "errorfiles", "errorloc", "errorloc302",
              "errorloc303" and section 3.8 about http-errors.