From d54e8f8107165de549bfbd78c5c0b8e549c9f880 Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w@1wt.eu>
Date: Thu, 30 Nov 2023 09:28:39 +0100
Subject: [PATCH] DOC: config: reorganize actions into their own section

The split of the rulesets from their respective actions has long been
overdue so it's time to do it because it has become extremely difficult
to add simple actions in the documentation, as well as it's hard to find
them.

This commit creates two new sections "4.3 Actions keywords matrix" and
"4.4 Alphabetically sorted actions reference" that enumerates all known
actions, with a check indicating for which rule sets they're valid. This
removes all the repetition, occurrences of "see http-request blah for
details" and significantly reduces the number of keywords listed in the
proxies section. This removes 2245 lines from the proxies section in
exchange of 1608 in these new sections.
---
 doc/configuration.txt | 3853 +++++++++++++++++------------------------
 1 file changed, 1608 insertions(+), 2245 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 59c685e56e..2c7ada20f6 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -60,6 +60,8 @@ Summary
 4.    Proxies
 4.1.      Proxy keywords matrix
 4.2.      Alphabetically sorted keywords reference
+4.3.      Actions keywords matrix
+4.4.      Alphabetically sorted actions reference
 
 5.    Bind and server options
 5.1.      Bind options
@@ -6246,44 +6248,29 @@ http-after-response <action> <options...> [ { if | unless } <condition> ]
 
   The http-after-response statement defines a set of rules which apply to layer
   7 processing. The rules are evaluated in their declaration order when they
-  are met in a frontend, listen or backend section. Any rule may optionally be
-  followed by an ACL-based condition, in which case it will only be evaluated
-  if the condition is true. Since these rules apply on responses, the backend
-  rules are applied first, followed by the frontend's rules.
+  are met in a frontend, listen or backend section. Since these rules apply on
+  responses, the backend rules are applied first, followed by the frontend's
+  rules. Any rule may optionally be followed by an ACL-based condition, in
+  which case it will only be evaluated if the condition evaluates true.
 
   Unlike http-response rules, these ones are applied on all responses, the
   server ones but also to all responses generated by HAProxy. These rules are
-  evaluated at the end of the responses analysis, before the data forwarding.
+  evaluated at the end of the responses analysis, before the data forwarding
+  phase.
 
-  The first keyword is the rule's action. Several types of actions are
-  supported:
-    - add-header <name> <fmt>
-    - allow
-    - capture <sample> id <id>
-    - del-acl(<file-name>) <key fmt>
-    - del-header <name> [ -m <meth> ]
-    - del-map(<file-name>) <key fmt>
-    - replace-header <name> <regex-match> <replace-fmt>
-    - replace-value <name> <regex-match> <replace-fmt>
-    - sc-add-gpc(<idx>,<sc-id>) { <int> | <expr> }
-    - sc-inc-gpc(<idx>,<sc-id>)
-    - sc-inc-gpc0(<sc-id>)
-    - sc-inc-gpc1(<sc-id>)
-    - sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
-    - sc-set-gpt0(<sc-id>) { <int> | <expr> }
-    - set-header <name> <fmt>
-    - set-log-level <level>
-    - set-map(<file-name>) <key fmt> <value fmt>
-    - set-status <status> [reason <str>]
-    - set-var(<var-name>[,<cond>...]) <expr>
-    - set-var-fmt(<var-name>[,<cond>...]) <fmt>
-    - strict-mode { on | off }
-    - unset-var(<var-name>)
+  The condition is evaluated just before the action is executed, and the action
+  is performed exactly once. As such, there is no problem if an action changes
+  an element which is checked as part of the condition. This also means that
+  multiple actions may rely on the same condition so that the first action that
+  changes the condition's evaluation is sufficient to implicitly disable the
+  remaining actions. This is used for example when trying to assign a value to
+  a variable from various sources when it's empty. There is no limit to the
+  number of "http-after-response" statements per instance.
 
-  The supported actions are described below.
-
-  There is no limit to the number of http-after-response statements per
-  instance.
+  The first keyword after "http-after-response" in the syntax is the rule's
+  action, optionally followed by a varying number of arguments for the action.
+  The supported actions and their respective syntaxes are enumerated in section
+  4.3 "Actions" (look for actions which tick "HTTP Aft").
 
   This directive is only available from named defaults sections, not anonymous
   ones. Rules defined in the defaults section are evaluated before ones in the
@@ -6301,134 +6288,6 @@ http-after-response <action> <options...> [ { if | unless } <condition> ]
     http-after-response set-header Cache-Control "no-store,no-cache,private"
     http-after-response set-header Pragma "no-cache"
 
-http-after-response add-header <name> <fmt> [ { if | unless } <condition> ]
-
-  This appends an HTTP header field whose name is specified in <name> and whose
-  value is defined by <fmt>. Please refer to "http-request add-header" for a
-  complete description.
-
-http-after-response allow [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and lets the response pass the check.
-  No further "http-after-response" rules are evaluated for the current section.
-
-http-after-response capture <sample> id <id> [ { if | unless } <condition> ]
-
-  This captures sample expression <sample> from the response buffer, and
-  converts it to a string. Please refer to "http-response capture" for a
-  complete description.
-
-http-after-response del-acl(<file-name>) <key fmt> [ { if | unless } <condition> ]
-
-  This is used to delete an entry from an ACL. Please refer to "http-request
-  del-acl" for a complete description.
-
-http-after-response del-header <name> [ -m <meth> ] [ { if | unless } <condition> ]
-
-  This removes all HTTP header fields whose name is specified in <name>. Please
-  refer to "http-request del-header" for a complete description.
-
-http-after-response del-map(<file-name>) <key fmt> [ { if | unless } <condition> ]
-
-  This is used to delete an entry from a MAP. Please refer to "http-request
-  del-map" for a complete description.
-
-http-after-response replace-header <name> <regex-match> <replace-fmt>
-                                   [ { if | unless } <condition> ]
-
-  This works like "http-response replace-header".
-
-  Example:
-    http-after-response replace-header Set-Cookie (C=[^;]*);(.*) \1;ip=%bi;\2
-
-    # applied to:
-    Set-Cookie: C=1; expires=Tue, 14-Jun-2016 01:40:45 GMT
-
-    # outputs:
-    Set-Cookie: C=1;ip=192.168.1.20; expires=Tue, 14-Jun-2016 01:40:45 GMT
-
-    # assuming the backend IP is 192.168.1.20.
-
-http-after-response replace-value <name> <regex-match> <replace-fmt>
-                                 [ { if | unless } <condition> ]
-
-  This works like "http-response replace-value".
-
-  Example:
-    http-after-response replace-value Cache-control ^public$ private
-
-    # applied to:
-    Cache-Control: max-age=3600, public
-
-    # outputs:
-    Cache-Control: max-age=3600, private
-
-http-after-response sc-add-gpc(<idx>,<sc-id>) { <int> | <expr> }
-                                           [ { if | unless } <condition> ]
-
-  This action increments the General Purpose Counter according to the sticky
-  counter designated by <sc-id>. Please refer to "http-request sc-add-gpc" for
-  a complete description.
-
-http-after-response sc-inc-gpc(<idx>,<sc-id>) [ { if | unless } <condition> ]
-http-after-response sc-inc-gpc0(<sc-id>) [ { if | unless } <condition> ]
-http-after-response sc-inc-gpc1(<sc-id>) [ { if | unless } <condition> ]
-
-  These actions increment the General Purppose Counters according to the sticky
-  counter designated by <sc-id>. Please refer to "http-request sc-inc-gpc",
-  "http-request sc-inc-gpc0" and "http-request sc-inc-gpc1" for a complete
-  description.
-
-http-after-response sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
-                                              [ { if | unless } <condition> ]
-http-after-response sc-set-gpt0(<sc-id>) { <int> | <expr> }
-                                         [ { if | unless } <condition> ]
-
-  These actions set the 32-bit unsigned General Purpose Tags according to the
-  sticky counter designated by <sc-id>. Please refer to "http-request
-  sc-set-gpt" and "http-request sc-set-gpt0" for a complete description.
-
-http-after-response set-log-level <level> [ { if | unless } <condition> ]
-
-  This is used to change the log level of the current response. Please refer to
-  "http-request set-log-level" for a complete description.
-
-http-after-response set-map(<file-name>) <key fmt> <value fmt>
-
-  This is used to add a new entry into a MAP. Please refer to "http-request
-  set-map" for a complete description.
-
-http-after-response set-header <name> <fmt> [ { if | unless } <condition> ]
-
-  This does the same as "http-after-response add-header" except that the header
-  name is first removed if it existed. This is useful when passing security
-  information to the server, where the header must not be manipulated by
-  external users.
-
-http-after-response set-status <status> [reason <str>]
-                               [ { if | unless } <condition> ]
-
-  This replaces the response status code with <status> which must be an integer
-  between 100 and 999. Please refer to "http-response set-status" for a complete
-  description.
-
-http-after-response set-var(<var-name>[,<cond>...]) <expr> [ { if | unless } <condition> ]
-http-after-response set-var-fmt(<var-name>[,<cond>...]) <fmt> [ { if | unless } <condition> ]
-
-  This is used to set the contents of a variable. The variable is declared
-  inline. Please refer to "http-request set-var" and "http-request set-var-fmt"
-  for a complete description.
-
-http-after-response strict-mode { on | off }  [ { if | unless } <condition> ]
-
-  This enables or disables the strict rewriting mode for following
-  rules. Please refer to "http-request strict-mode" for a complete description.
-
-http-after-response unset-var(<var-name>) [ { if | unless } <condition> ]
-
-  This is used to unset a variable. See "http-request set-var" for details
-  about <var-name>.
-
 
 http-check comment <string>
   Defines a comment for the following the http-check rule, reported in logs if
@@ -6994,75 +6853,21 @@ http-request <action> [options...] [ { if | unless } <condition> ]
   processing. The rules are evaluated in their declaration order when they are
   met in a frontend, listen or backend section. Any rule may optionally be
   followed by an ACL-based condition, in which case it will only be evaluated
-  if the condition is true.
+  if the condition evaluates to true.
 
-  The first keyword is the rule's action. Several types of actions are
-  supported:
-    - add-acl(<file-name>) <key fmt>
-    - add-header <name> <fmt>
-    - allow
-    - auth [realm <realm>]
-    - cache-use <name>
-    - capture <sample> [ len <length> | id <id> ]
-    - del-acl(<file-name>) <key fmt>
-    - del-header <name> [ -m <meth> ]
-    - del-map(<file-name>) <key fmt>
-    - deny [ { status | deny_status } <code>]  ...
-    - disable-l7-retry
-    - do-resolve(<var>,<resolvers>,[ipv4,ipv6]) <expr>
-    - early-hint <name> <fmt>
-    - normalize-uri <normalizer>
-    - redirect <rule>
-    - reject
-    - replace-header <name> <match-regex> <replace-fmt>
-    - replace-path <match-regex> <replace-fmt>
-    - replace-pathq <match-regex> <replace-fmt>
-    - replace-uri <match-regex> <replace-fmt>
-    - replace-value <name> <match-regex> <replace-fmt>
-    - return [status <code>] [content-type <type>] ...
-    - sc-add-gpc(<idx>,<sc-id>) { <int> | <expr> }
-    - sc-inc-gpc(<idx>,<sc-id>)
-    - sc-inc-gpc0(<sc-id>)
-    - sc-inc-gpc1(<sc-id>)
-    - sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
-    - sc-set-gpt0(<sc-id>) { <int> | <expr> }
-    - set-bandwidth-limit <name> [limit {<expr> | <size>}] [period {<expr> | <time>}]
-    - set-dst <expr>
-    - set-dst-port <expr>
-    - set-header <name> <fmt>
-    - set-log-level <level>
-    - set-map(<file-name>) <key fmt> <value fmt>
-    - set-mark <mark>
-    - set-method <fmt>
-    - set-nice <nice>
-    - set-path <fmt>
-    - set-pathq <fmt>
-    - set-priority-class <expr>
-    - set-priority-offset <expr>
-    - set-query <fmt>
-    - set-src <expr>
-    - set-src-port <expr>
-    - set-timeout { client | server | tunnel } { <timeout> | <expr> }
-    - set-tos <tos>
-    - set-uri <fmt>
-    - set-var(<var-name>[,<cond>...]) <expr>
-    - set-var-fmt(<var-name>[,<cond>...]) <fmt>
-    - send-spoe-group <engine-name> <group-name>
-    - silent-drop [ rst-ttl <ttl> ]
-    - strict-mode { on | off }
-    - tarpit [ { status | deny_status } <code>] ...
-    - track-sc0 <key> [table <table>]
-    - track-sc1 <key> [table <table>]
-    - track-sc2 <key> [table <table>]
-    - unset-var(<var-name>)
-    - use-service <service-name>
-    - wait-for-body time <time> [ at-least <bytes> ]
-    - wait-for-handshake
-    - cache-use <name>
+  The condition is evaluated just before the action is executed, and the action
+  is performed exactly once. As such, there is no problem if an action changes
+  an element which is checked as part of the condition. This also means that
+  multiple actions may rely on the same condition so that the first action that
+  changes the condition's evaluation is sufficient to implicitly disable the
+  remaining actions. This is used for example when trying to assign a value to
+  a variable from various sources when it's empty. There is no limit to the
+  number of "http-request" statements per instance.
 
-  The supported actions are described below.
-
-  There is no limit to the number of http-request statements per instance.
+  The first keyword after "http-request" in the syntax is the rule's action,
+  optionally followed by a varying number of arguments for the action. The
+  supported actions and their respective syntaxes are enumerated in section 4.3
+  "Actions" (look for actions which tick "HTTP Req").
 
   This directive is only available from named defaults sections, not anonymous
   ones. Rules defined in the defaults section are evaluated before ones in the
@@ -7104,1098 +6909,6 @@ http-request <action> [options...] [ { if | unless } <condition> ]
   See also : "stats http-request", section 3.4 about userlists and section 7
              about ACL usage.
 
-http-request add-acl(<file-name>) <key fmt> [ { if | unless } <condition> ]
-
-  This is used to add a new entry into an ACL. The ACL must be loaded from a
-  file (even a dummy empty file). The file name of the ACL to be updated is
-  passed between parentheses. It takes one argument: <key fmt>, which follows
-  log-format rules, to collect content of the new entry. It performs a lookup
-  in the ACL before insertion, to avoid duplicated (or more) values.
-  It is the equivalent of the "add acl" command from the stats socket, but can
-  be triggered by an HTTP request.
-
-http-request add-header <name> <fmt> [ { if | unless } <condition> ]
-
-  This appends an HTTP header field whose name is specified in <name> and
-  whose value is defined by <fmt> which follows the log-format rules (see
-  Custom Log Format in section 8.2.4). This is particularly useful to pass
-  connection-specific information to the server (e.g. the client's SSL
-  certificate), or to combine several headers into one. This rule is not
-  final, so it is possible to add other similar rules. Note that header
-  addition is performed immediately, so one rule might reuse the resulting
-  header from a previous rule.
-
-http-request allow [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and lets the request pass the check.
-  No further "http-request" rules are evaluated for the current section.
-
-http-request auth [realm <realm>] [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and immediately responds with an
-  HTTP 401 or 407 error code to invite the user to present a valid user name
-  and password. No further "http-request" rules are evaluated. An optional
-  "realm" parameter is supported, it sets the authentication realm that is
-  returned with the response (typically the application's name).
-
-  The corresponding proxy's error message is used. It may be customized using
-  an "errorfile" or an "http-error" directive. For 401 responses, all
-  occurrences of the WWW-Authenticate header are removed and replaced by a new
-  one with a basic authentication challenge for realm "<realm>". For 407
-  responses, the same is done on the Proxy-Authenticate header. If the error
-  message must not be altered, consider to use "http-request return" rule
-  instead.
-
-  Example:
-        acl auth_ok http_auth_group(L1) G1
-        http-request auth unless auth_ok
-
-http-request cache-use <name> [ { if | unless } <condition> ]
-
-  See section 6.2 about cache setup.
-
-http-request capture <sample> [ len <length> | id <id> ]
-                     [ { if | unless } <condition> ]
-
-  This captures sample expression <sample> from the request buffer, and
-  converts it to a string of at most <len> characters. The resulting string is
-  stored into the next request "capture" slot, so it will possibly appear next
-  to some captured HTTP headers. It will then automatically appear in the logs,
-  and it will be possible to extract it using sample fetch rules to feed it
-  into headers or anything. The length should be limited given that this size
-  will be allocated for each capture during the whole session life.
-  Please check section 7.3 (Fetching samples) and "capture request header" for
-  more information.
-
-  If the keyword "id" is used instead of "len", the action tries to store the
-  captured string in a previously declared capture slot. This is useful to run
-  captures in backends. The slot id can be declared by a previous directive
-  "http-request capture" or with the "declare capture" keyword.
-
-  When using this action in a backend, double check that the relevant
-  frontend(s) have the required capture slots otherwise, this rule will be
-  ignored at run time. This can't be detected at configuration parsing time
-  due to HAProxy's ability to dynamically resolve backend name at runtime.
-
-http-request del-acl(<file-name>) <key fmt> [ { if | unless } <condition> ]
-
-  This is used to delete an entry from an ACL. The ACL must be loaded from a
-  file (even a dummy empty file). The file name of the ACL to be updated is
-  passed between parentheses. It takes one argument: <key fmt>, which follows
-  log-format rules, to collect content of the entry to delete.
-  It is the equivalent of the "del acl" command from the stats socket, but can
-  be triggered by an HTTP request.
-
-http-request del-header <name> [ -m <meth> ] [ { if | unless } <condition> ]
-
-  This removes all HTTP header fields whose name is specified in <name>. <meth>
-  is the matching method, applied on the header name. Supported matching methods
-  are "str" (exact match), "beg" (prefix match), "end" (suffix match), "sub"
-  (substring match) and "reg" (regex match). If not specified, exact matching
-  method is used.
-
-http-request del-map(<file-name>) <key fmt> [ { if | unless } <condition> ]
-
-  This is used to delete an entry from a MAP. The MAP must be loaded from a
-  file (even a dummy empty file). The file name of the MAP to be updated is
-  passed between parentheses. It takes one argument: <key fmt>, which follows
-  log-format rules, to collect content of the entry to delete.
-  It takes one argument: "file name" It is the equivalent of the "del map"
-  command from the stats socket, but can be triggered by an HTTP request.
-
-http-request deny [deny_status <status>] [ { if | unless } <condition> ]
-http-request deny [ { status | deny_status } <code>] [content-type <type>]
-          [ { default-errorfiles | errorfile <file> | errorfiles <name> |
-              file <file> | lf-file <file> | string <str> | lf-string <fmt> } ]
-          [ hdr <name> <fmt> ]*
-          [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and immediately rejects the request.
-  By default an HTTP 403 error is returned. But the response may be customized
-  using same syntax than "http-request return" rules. Thus, see "http-request
-  return" for details. For compatibility purpose, when no argument is defined,
-  or only "deny_status", the argument "default-errorfiles" is implied. It means
-  "http-request deny [deny_status <status>]" is an alias of
-  "http-request deny [status <status>] default-errorfiles".
-  No further "http-request" rules are evaluated.
-  See also "http-request return".
-
-http-request disable-l7-retry [ { if | unless } <condition> ]
-  This disables any attempt to retry the request if it fails for any other
-  reason than a connection failure. This can be useful for example to make
-  sure POST requests aren't retried on failure.
-
-http-request do-resolve(<var>,<resolvers>,[ipv4,ipv6]) <expr>
-             [ { if | unless } <condition> ]
-
-  This action performs a DNS resolution of the output of <expr> and stores
-  the result in the variable <var>. It uses the DNS resolvers section
-  pointed by <resolvers>.
-  It is possible to choose a resolution preference using the optional
-  arguments 'ipv4' or 'ipv6'.
-  When performing the DNS resolution, the client side connection is on
-  pause waiting till the end of the resolution.
-  If an IP address can be found, it is stored into <var>. If any kind of
-  error occurs, then <var> is not set.
-  One can use this action to discover a server IP address at run time and
-  based on information found in the request (IE a Host header).
-  If this action is used to find the server's IP address (using the
-  "set-dst" action), then the server IP address in the backend must be set
-  to 0.0.0.0. The do-resolve action takes an host-only parameter, any port must
-  be removed from the string.
-
-  Example:
-    resolvers mydns
-      nameserver local 127.0.0.53:53
-      nameserver google 8.8.8.8:53
-      timeout retry   1s
-      hold valid 10s
-      hold nx 3s
-      hold other 3s
-      hold obsolete 0s
-      accepted_payload_size 8192
-
-    frontend fe
-      bind 10.42.0.1:80
-      http-request do-resolve(txn.myip,mydns,ipv4) hdr(Host),host_only
-      http-request capture var(txn.myip) len 40
-
-      # return 503 when the variable is not set,
-      # which mean DNS resolution error
-      use_backend b_503 unless { var(txn.myip) -m found }
-
-      default_backend be
-
-    backend b_503
-      # dummy backend used to return 503.
-      # one can use the errorfile directive to send a nice
-      # 503 error page to end users
-
-    backend be
-      # rule to prevent HAProxy from reconnecting to services
-      # on the local network (forged DNS name used to scan the network)
-      http-request deny if { var(txn.myip) -m ip 127.0.0.0/8 10.0.0.0/8 }
-      http-request set-dst var(txn.myip)
-      server clear 0.0.0.0:0
-
-  NOTE: Don't forget to set the "protection" rules to ensure HAProxy won't
-        be used to scan the network or worst won't loop over itself...
-
-http-request early-hint <name> <fmt> [ { if | unless } <condition> ]
-
-  This is used to build an HTTP 103 Early Hints response prior to any other one.
-  This appends an HTTP header field to this response whose name is specified in
-  <name> and whose value is defined by <fmt> which follows the log-format rules
-  (see Custom Log Format in section 8.2.4). This is particularly useful to pass
-  to the client some Link headers to preload resources required to render the
-  HTML documents.
-
-  See RFC 8297 for more information.
-
-http-request normalize-uri <normalizer> [ { if | unless } <condition> ]
-http-request normalize-uri fragment-encode [ { if | unless } <condition> ]
-http-request normalize-uri fragment-strip [ { if | unless } <condition> ]
-http-request normalize-uri path-merge-slashes [ { if | unless } <condition> ]
-http-request normalize-uri path-strip-dot [ { if | unless } <condition> ]
-http-request normalize-uri path-strip-dotdot [ full ] [ { if | unless } <condition> ]
-http-request normalize-uri percent-decode-unreserved [ strict ] [ { if | unless } <condition> ]
-http-request normalize-uri percent-to-uppercase [ strict ] [ { if | unless } <condition> ]
-http-request normalize-uri query-sort-by-name [ { if | unless } <condition> ]
-
-  Performs normalization of the request's URI.
-
-  URI normalization in HAProxy 2.4 is currently available as an experimental
-  technical preview. As such, it requires the global directive
-  'expose-experimental-directives' first to be able to invoke it. You should be
-  prepared that the behavior of normalizers might change to fix possible
-  issues, possibly breaking proper request processing in your infrastructure.
-
-  Each normalizer handles a single type of normalization to allow for a
-  fine-grained selection of the level of normalization that is appropriate for
-  the supported backend.
-
-  As an example the "path-strip-dotdot" normalizer might be useful for a static
-  fileserver that directly maps the requested URI to the path within the local
-  filesystem. However it might break routing of an API that expects a specific
-  number of segments in the path.
-
-  It is important to note that some normalizers might result in unsafe
-  transformations for broken URIs. It might also be possible that a combination
-  of normalizers that are safe by themselves results in unsafe transformations
-  when improperly combined.
-
-  As an example the "percent-decode-unreserved" normalizer might result in
-  unexpected results when a broken URI includes bare percent characters. One
-  such a broken URI is "/%%36%36" which would be decoded to "/%66" which in
-  turn is equivalent to "/f". By specifying the "strict" option requests to
-  such a broken URI would safely be rejected.
-
-  The following normalizers are available:
-
-  - fragment-encode: Encodes "#" as "%23".
-
-      The "fragment-strip" normalizer should be preferred, unless it is known
-      that broken clients do not correctly encode '#' within the path component.
-
-      Example:
-      - /#foo  -> /%23foo
-
-  - fragment-strip: Removes the URI's "fragment" component.
-
-      According to RFC 3986#3.5 the "fragment" component of an URI should not
-      be sent, but handled by the User Agent after retrieving a resource.
-
-      This normalizer should be applied first to ensure that the fragment is
-      not interpreted as part of the request's path component.
-
-      Example:
-      - /#foo  -> /
-
-  - path-strip-dot: Removes "/./" segments within the "path" component
-      (RFC 3986#6.2.2.3).
-
-      Segments including percent encoded dots ("%2E") will not be detected. Use
-      the "percent-decode-unreserved" normalizer first if this is undesired.
-
-      Example:
-      - /.            -> /
-      - /./bar/       -> /bar/
-      - /a/./a        -> /a/a
-      - /.well-known/ -> /.well-known/ (no change)
-
-  - path-strip-dotdot: Normalizes "/../" segments within the "path" component
-      (RFC 3986#6.2.2.3).
-
-      This merges segments that attempt to access the parent directory with
-      their preceding segment.
-
-      Empty segments do not receive special treatment. Use the "merge-slashes"
-      normalizer first if this is undesired.
-
-      Segments including percent encoded dots ("%2E") will not be detected. Use
-      the "percent-decode-unreserved" normalizer first if this is undesired.
-
-      Example:
-      - /foo/../     -> /
-      - /foo/../bar/ -> /bar/
-      - /foo/bar/../ -> /foo/
-      - /../bar/     -> /../bar/
-      - /bar/../../  -> /../
-      - /foo//../    -> /foo/
-      - /foo/%2E%2E/ -> /foo/%2E%2E/
-
-      If the "full" option is specified then "../" at the beginning will be
-      removed as well:
-
-      Example:
-      - /../bar/     -> /bar/
-      - /bar/../../  -> /
-
-  - path-merge-slashes: Merges adjacent slashes within the "path" component
-      into a single slash.
-
-      Example:
-      - //        -> /
-      - /foo//bar -> /foo/bar
-
-  - percent-decode-unreserved: Decodes unreserved percent encoded characters to
-      their representation as a regular character (RFC 3986#6.2.2.2).
-
-      The set of unreserved characters includes all letters, all digits, "-",
-      ".", "_", and "~".
-
-      Example:
-      - /%61dmin       -> /admin
-      - /foo%3Fbar=baz -> /foo%3Fbar=baz (no change)
-      - /%%36%36       -> /%66           (unsafe)
-      - /%ZZ           -> /%ZZ
-
-      If the "strict" option is specified then invalid sequences will result
-      in a HTTP 400 Bad Request being returned.
-
-      Example:
-      - /%%36%36 -> HTTP 400
-      - /%ZZ     -> HTTP 400
-
-  - percent-to-uppercase: Uppercases letters within percent-encoded sequences
-      (RFC 3986#6.2.2.1).
-
-      Example:
-      - /%6f -> /%6F
-      - /%zz -> /%zz
-
-      If the "strict" option is specified then invalid sequences will result
-      in a HTTP 400 Bad Request being returned.
-
-      Example:
-      - /%zz -> HTTP 400
-
-  - query-sort-by-name: Sorts the query string parameters by parameter name.
-      Parameters are assumed to be delimited by '&'. Shorter names sort before
-      longer names and identical parameter names maintain their relative order.
-
-      Example:
-      - /?c=3&a=1&b=2         -> /?a=1&b=2&c=3
-      - /?aaa=3&a=1&aa=2      -> /?a=1&aa=2&aaa=3
-      - /?a=3&b=4&a=1&b=5&a=2 -> /?a=3&a=1&a=2&b=4&b=5
-
-http-request redirect <rule> [ { if | unless } <condition> ]
-
-  This performs an HTTP redirection based on a redirect rule. This is exactly
-  the same as the "redirect" statement except that it inserts a redirect rule
-  which can be processed in the middle of other "http-request" rules and that
-  these rules use the "log-format" strings. See the "redirect" keyword for the
-  rule's syntax.
-
-http-request reject [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and immediately closes the connection
-  without sending any response. It acts similarly to the
-  "tcp-request content reject" rules. It can be useful to force an immediate
-  connection closure on HTTP/2 connections.
-
-http-request replace-header <name> <match-regex> <replace-fmt>
-                            [ { if | unless } <condition> ]
-
-  This matches the value of all occurrences of header field <name> against
-  <match-regex>. Matching is performed case-sensitively. Matching values are
-  completely replaced by <replace-fmt>. Format characters are allowed in
-  <replace-fmt> and work like <fmt> arguments in "http-request add-header".
-  Standard back-references using the backslash ('\') followed by a number are
-  supported.
-
-  This action acts on whole header lines, regardless of the number of values
-  they may contain. Thus it is well-suited to process headers naturally
-  containing commas in their value, such as If-Modified-Since. Headers that
-  contain a comma-separated list of values, such as Accept, should be processed
-  using "http-request replace-value".
-
-  Example:
-    http-request replace-header Cookie foo=([^;]*);(.*) foo=\1;ip=%bi;\2
-
-    # applied to:
-    Cookie: foo=foobar; expires=Tue, 14-Jun-2016 01:40:45 GMT;
-
-    # outputs:
-    Cookie: foo=foobar;ip=192.168.1.20; expires=Tue, 14-Jun-2016 01:40:45 GMT;
-
-    # assuming the backend IP is 192.168.1.20
-
-    http-request replace-header User-Agent curl foo
-
-    # applied to:
-    User-Agent: curl/7.47.0
-
-    # outputs:
-    User-Agent: foo
-
-http-request replace-path <match-regex> <replace-fmt>
-                           [ { if | unless } <condition> ]
-
-  This works like "replace-header" except that it works on the request's path
-  component instead of a header. The path component starts at the first '/'
-  after an optional scheme+authority and ends before the question mark. Thus,
-  the replacement does not modify the scheme, the authority and the
-  query-string.
-
-  It is worth noting that regular expressions may be more expensive to evaluate
-  than certain ACLs, so rare replacements may benefit from a condition to avoid
-  performing the evaluation at all if it does not match.
-
-  Example:
-    # prefix /foo : turn /bar?q=1 into /foo/bar?q=1 :
-    http-request replace-path (.*) /foo\1
-
-    # strip /foo : turn /foo/bar?q=1 into /bar?q=1
-    http-request replace-path /foo/(.*) /\1
-    # or more efficient if only some requests match :
-    http-request replace-path /foo/(.*) /\1 if { url_beg /foo/ }
-
-http-request replace-pathq <match-regex> <replace-fmt>
-                           [ { if | unless } <condition> ]
-
-  This does the same as "http-request replace-path" except that the path
-  contains the query-string if any is present. Thus, the path and the
-  query-string are replaced.
-
-  Example:
-    # suffix /foo : turn /bar?q=1 into /bar/foo?q=1 :
-    http-request replace-pathq ([^?]*)(\?(.*))? \1/foo\2
-
-http-request replace-uri <match-regex> <replace-fmt>
-                           [ { if | unless } <condition> ]
-
-  This works like "replace-header" except that it works on the request's URI part
-  instead of a header. The URI part may contain an optional scheme, authority or
-  query string. These are considered to be part of the value that is matched
-  against.
-
-  It is worth noting that regular expressions may be more expensive to evaluate
-  than certain ACLs, so rare replacements may benefit from a condition to avoid
-  performing the evaluation at all if it does not match.
-
-  IMPORTANT NOTE: historically in HTTP/1.x, the vast majority of requests sent
-  by browsers use the "origin form", which differs from the "absolute form" in
-  that they do not contain a scheme nor authority in the URI portion. Mostly
-  only requests sent to proxies, those forged by hand and some emitted by
-  certain applications use the absolute form. As such, "replace-uri" usually
-  works fine most of the time in HTTP/1.x with rules starting with a "/". But
-  with HTTP/2, clients are encouraged to send absolute URIs only, which look
-  like the ones HTTP/1 clients use to talk to proxies. Such partial replace-uri
-  rules may then fail in HTTP/2 when they work in HTTP/1. Either the rules need
-  to be adapted to optionally match a scheme and authority, or replace-path
-  should be used.
-
-  Example:
-    # rewrite all "http" absolute requests to "https":
-    http-request replace-uri ^http://(.*) https://\1
-
-    # prefix /foo : turn /bar?q=1 into /foo/bar?q=1 :
-    http-request replace-uri ([^/:]*://[^/]*)?(.*) \1/foo\2
-
-http-request replace-value <name> <match-regex> <replace-fmt>
-                           [ { if | unless } <condition> ]
-
-  This works like "replace-header" except that it matches the regex against
-  every comma-delimited value of the header field <name> instead of the
-  entire header. This is suited for all headers which are allowed to carry
-  more than one value. An example could be the Accept header.
-
-  Example:
-    http-request replace-value X-Forwarded-For ^192\.168\.(.*)$ 172.16.\1
-
-    # applied to:
-    X-Forwarded-For: 192.168.10.1, 192.168.13.24, 10.0.0.37
-
-    # outputs:
-    X-Forwarded-For: 172.16.10.1, 172.16.13.24, 10.0.0.37
-
-http-request return [status <code>] [content-type <type>]
-          [ { default-errorfiles | errorfile <file> | errorfiles <name> |
-              file <file> | lf-file <file> | string <str> | lf-string <fmt> } ]
-          [ hdr <name> <fmt> ]*
-          [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and immediately returns a response. The
-  default status code used for the response is 200. It can be optionally
-  specified as an arguments to "status". The response content-type may also be
-  specified as an argument to "content-type". Finally the response itself may
-  be defined. It can be a full HTTP response specifying the errorfile to use,
-  or the response payload specifying the file or the string to use. These rules
-  are followed to create the response :
-
-  * If neither the errorfile nor the payload to use is defined, a dummy
-    response is returned. Only the "status" argument is considered. It can be
-    any code in the range [200, 599]. The "content-type" argument, if any, is
-    ignored.
-
-  * If "default-errorfiles" argument is set, the proxy's errorfiles are
-    considered.  If the "status" argument is defined, it must be one of the
-    status code handled by HAProxy (200, 400, 403, 404, 405, 408, 410, 413,
-    425, 429, 500, 501, 502, 503, and 504). The "content-type" argument, if
-    any, is ignored.
-
-  * If a specific errorfile is defined, with an "errorfile" argument, the
-    corresponding file, containing a full HTTP response, is returned. Only the
-    "status" argument is considered. It must be one of the status code handled
-    by HAProxy (200, 400, 403, 404, 405, 408, 410, 413, 425, 429, 500, 501,
-    502, 503, and 504). The "content-type" argument, if any, is ignored.
-
-  * If an http-errors section is defined, with an "errorfiles" argument, the
-    corresponding file in the specified http-errors section, containing a full
-    HTTP response, is returned. Only the "status" argument is considered. It
-    must be one of the status code handled by HAProxy (200, 400, 403, 404, 405,
-    408, 410, 413, 425, 429, 500, 501, 502, 503, and 504). The "content-type"
-    argument, if any, is ignored.
-
-  * If a "file" or a "lf-file" argument is specified, the file's content is
-    used as the response payload. If the file is not empty, its content-type
-    must be set as argument to "content-type". Otherwise, any "content-type"
-    argument is ignored. With a "lf-file" argument, the file's content is
-    evaluated as a log-format string. With a "file" argument, it is considered
-    as a raw content.
-
-  * If a "string" or "lf-string" argument is specified, the defined string is
-    used as the response payload. The content-type must always be set as
-    argument to "content-type". With a "lf-string" argument, the string is
-    evaluated as a log-format string. With a "string" argument, it is
-    considered as a raw string.
-
-  When the response is not based on an errorfile, it is possible to append HTTP
-  header fields to the response using "hdr" arguments. Otherwise, all "hdr"
-  arguments are ignored. For each one, the header name is specified in <name>
-  and its value is defined by <fmt> which follows the log-format rules.
-
-  Note that the generated response must be smaller than a buffer. And to avoid
-  any warning, when an errorfile or a raw file is loaded, the buffer space
-  reserved for the headers rewriting should also be free.
-
-  No further "http-request" rules are evaluated.
-
-  Example:
-    http-request return errorfile /etc/haproxy/errorfiles/200.http \
-        if { path /ping }
-
-    http-request return content-type image/x-icon file /var/www/favicon.ico  \
-        if { path /favicon.ico }
-
-    http-request return status 403 content-type text/plain    \
-        lf-string "Access denied. IP %[src] is blacklisted."  \
-        if { src -f /etc/haproxy/blacklist.lst }
-
-http-request sc-add-gpc(<idx>,<sc-id>) { <int> | <expr> }
-                                           [ { if | unless } <condition> ]
-
-  This action increments the General Purpose Counter at the index <idx> of the
-  array associated to the sticky counter designated by <sc-id> by the value of
-  either integer <int> or the integer evaluation of expression <expr>. Integers
-  and expressions are limited to unsigned 32-bit values. If an error occurs,
-  this action silently fails and the actions evaluation continues. <idx> is an
-  integer between 0 and 99 and <sc-id> is an integer between 0 and 2. It also
-  silently fails if the there is no GPC stored at this index. The entry in the
-  table is refreshed even if the value is zero. The 'gpc_rate' is automatically
-  adjusted to reflect the average growth rate of the gpc value.
-
-  This action applies only to the 'gpc' and 'gpc_rate' array data_types (and
-  not to the legacy 'gpc0', 'gpc1', 'gpc0_rate' nor 'gpc1_rate' data_types).
-  There is no equivalent function for legacy data types, but if the value is
-  always 1, please see 'sc-inc-gpc()', 'sc-inc-gpc0()' and 'sc-inc-gpc1()'.
-  There is no way to decrement the value either, but it is possible to store
-  exact values in a General Purpose Tag using 'sc-set-gpt()' instead.
-
-  The main use of this action is to count scores or total volumes (e.g.
-  estimated danger per source IP reported by the server or a WAF, total
-  uploaded bytes, etc).
-
-http-request sc-inc-gpc(<idx>,<sc-id>) [ { if | unless } <condition> ]
-
-  This actions increments the General Purpose Counter at the index <idx>
-  of the array associated to the sticky counter designated by <sc-id>.
-  If an error occurs, this action silently fails and the actions evaluation
-  continues. <idx> is an integer between 0 and 99 and <sc-id> is an integer
-  between 0 and 2. It also silently fails if the there is no GPC stored
-  at this index.
-  This action applies only to the 'gpc' and 'gpc_rate' array data_types (and
-  not to the legacy 'gpc0', 'gpc1', 'gpc0_rate' nor 'gpc1_rate' data_types).
-
-http-request sc-inc-gpc0(<sc-id>) [ { if | unless } <condition> ]
-http-request sc-inc-gpc1(<sc-id>) [ { if | unless } <condition> ]
-
-  This actions increments the GPC0 or GPC1 counter according with the sticky
-  counter designated by <sc-id>. If an error occurs, this action silently fails
-  and the actions evaluation continues.
-
-http-request sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
-                                           [ { if | unless } <condition> ]
-  This action sets the 32-bit unsigned GPT at the index <idx> of the array
-  associated to the sticky counter designated by <sc-id> at the value of
-  <int>/<expr>. The expected result is a boolean.
-  If an error occurs, this action silently fails and the actions evaluation
-  continues. <idx> is an integer between 0 and 99 and <sc-id> is an integer
-  between 0 and 2. It also silently fails if the there is no GPT stored
-  at this index.
-  This action applies only to the 'gpt' array data_type (and not to the
-  legacy 'gpt0' data-type).
-
-http-request sc-set-gpt0(<sc-id>) { <int> | <expr> }
-                                  [ { if | unless } <condition> ]
-
-  This action sets the 32-bit unsigned GPT0 tag according to the sticky counter
-  designated by <sc-id> and the value of <int>/<expr>. The expected result is a
-  boolean. If an error occurs, this action silently fails and the actions
-  evaluation continues.
-
-http-request send-spoe-group <engine-name> <group-name>
-                             [ { if | unless } <condition> ]
-
-  This action is used to trigger sending of a group of SPOE messages. To do so,
-  the SPOE engine used to send messages must be defined, as well as the SPOE
-  group to send. Of course, the SPOE engine must refer to an existing SPOE
-  filter. If not engine name is provided on the SPOE filter line, the SPOE
-  agent name must be used.
-
-  Arguments:
-    <engine-name>  The SPOE engine name.
-
-    <group-name>   The SPOE group name as specified in the engine
-                   configuration.
-
-http-request set-bandwidth-limit <name> [limit { <expr> | <size> }]
-                 [period { <expr> | <time> }] [ { if | unless } <condition> ]
-
-  This action is used to enable the bandwidth limitation filter <name>, either
-  on the upload or download direction depending on the filter type. Custom
-  limit and period may be defined, if and only if <name> references a
-  per-stream bandwidth limitation filter. When a set-bandwidth-limit rule is
-  executed, it first resets all settings of the filter to their defaults prior
-  to enabling it. As a consequence, if several "set-bandwidth-limit" actions
-  are executed for the same filter, only the last one is considered. Several
-  bandwidth limitation filters can be enabled on the same stream.
-
-  Note that this action cannot be used in a defaults section because bandwidth
-  limitation filters cannot be defined in defaults sections. In addition, only
-  the HTTP payload transfer is limited. The HTTP headers are not considered.
-
-  Arguments:
-    <expr>  Is a standard HAProxy expression formed by a sample-fetch followed
-            by some converters. The result is converted to an integer. It is
-            interpreted as a size in bytes for the "limit" parameter and as a
-            duration in milliseconds for the "period" parameter.
-
-    <size>  Is a number. It follows the HAProxy size format and is expressed in
-            bytes.
-
-    <time>  Is a number. It follows the HAProxy time format and is expressed in
-            milliseconds.
-
-  Example:
-    http-request set-bandwidth-limit global-limit
-    http-request set-bandwidth-limit my-limit limit 1m period 10s
-
-  See section 9.7 about bandwidth limitation filter setup.
-
-http-request set-dst <expr> [ { if | unless } <condition> ]
-
-  This is used to set the destination IP address to the value of specified
-  expression. Useful when a proxy in front of HAProxy rewrites destination IP,
-  but provides the correct IP in a HTTP header; or you want to mask the IP for
-  privacy. If you want to connect to the new address/port, use '0.0.0.0:0' as a
-  server address in the backend.
-
-  Arguments:
-    <expr>  Is a standard HAProxy expression formed by a sample-fetch followed
-            by some converters.
-
-  Example:
-    http-request set-dst hdr(x-dst)
-    http-request set-dst dst,ipmask(24)
-
-  When possible, set-dst preserves the original destination port as long as the
-  address family allows it, otherwise the destination port is set to 0.
-
-http-request set-dst-port <expr> [ { if | unless } <condition> ]
-
-  This is used to set the destination port address to the value of specified
-  expression. If you want to connect to the new address/port, use '0.0.0.0:0'
-  as a server address in the backend.
-
-  Arguments:
-    <expr>  Is a standard HAProxy expression formed by a sample-fetch
-            followed by some converters.
-
-  Example:
-    http-request set-dst-port hdr(x-port)
-    http-request set-dst-port int(4000)
-
-  When possible, set-dst-port preserves the original destination address as
-  long as the address family supports a port, otherwise it forces the
-  destination address to IPv4 "0.0.0.0" before rewriting the port.
-
-http-request set-header <name> <fmt> [ { if | unless } <condition> ]
-
-  This does the same as "http-request add-header" except that the header name
-  is first removed if it existed. This is useful when passing security
-  information to the server, where the header must not be manipulated by
-  external users. Note that the new value is computed before the removal so it
-  is possible to concatenate a value to an existing header.
-
-  Example:
-        http-request set-header X-Haproxy-Current-Date %T
-        http-request set-header X-SSL                  %[ssl_fc]
-        http-request set-header X-SSL-Session_ID       %[ssl_fc_session_id,hex]
-        http-request set-header X-SSL-Client-Verify    %[ssl_c_verify]
-        http-request set-header X-SSL-Client-DN        %{+Q}[ssl_c_s_dn]
-        http-request set-header X-SSL-Client-CN        %{+Q}[ssl_c_s_dn(cn)]
-        http-request set-header X-SSL-Issuer           %{+Q}[ssl_c_i_dn]
-        http-request set-header X-SSL-Client-NotBefore %{+Q}[ssl_c_notbefore]
-        http-request set-header X-SSL-Client-NotAfter  %{+Q}[ssl_c_notafter]
-
-http-request set-log-level <level> [ { if | unless } <condition> ]
-
-  This is used to change the log level of the current request when a certain
-  condition is met. Valid levels are the 8 syslog levels (see the "log"
-  keyword) plus the special level "silent" which disables logging for this
-  request. This rule is not final so the last matching rule wins. This rule
-  can be useful to disable health checks coming from another equipment.
-
-http-request set-map(<file-name>) <key fmt> <value fmt>
-                                  [ { if | unless } <condition> ]
-
-  This is used to add a new entry into a MAP. The MAP must be loaded from a
-  file (even a dummy empty file). The file name of the MAP to be updated is
-  passed between parentheses. It takes 2 arguments: <key fmt>, which follows
-  log-format rules, used to collect MAP key, and <value fmt>, which follows
-  log-format rules, used to collect content for the new entry.
-  It performs a lookup in the MAP before insertion, to avoid duplicated (or
-  more) values. It is the equivalent of the "set map" command from the
-  stats socket, but can be triggered by an HTTP request.
-
-http-request set-mark <mark> [ { if | unless } <condition> ]
-
-  This is used to set the Netfilter/IPFW MARK on all packets sent to the client
-  to the value passed in <mark> on platforms which support it. This value is an
-  unsigned 32 bit value which can be matched by netfilter/ipfw and by the
-  routing table or monitoring the packets through DTrace. It can be expressed
-  both in decimal or hexadecimal format (prefixed by "0x").
-  This can be useful to force certain packets to take a different route (for
-  example a cheaper network path for bulk downloads). This works on Linux
-  kernels 2.6.32 and above and requires admin privileges, as well on FreeBSD
-  and OpenBSD.
-
-http-request set-method <fmt> [ { if | unless } <condition> ]
-
-  This rewrites the request method with the result of the evaluation of format
-  string <fmt>. There should be very few valid reasons for having to do so as
-  this is more likely to break something than to fix it.
-
-http-request set-nice <nice> [ { if | unless } <condition> ]
-
-  This sets the "nice" factor of the current request being processed. It only
-  has effect against the other requests being processed at the same time.
-  The default value is 0, unless altered by the "nice" setting on the "bind"
-  line. The accepted range is -1024..1024. The higher the value, the nicest
-  the request will be. Lower values will make the request more important than
-  other ones. This can be useful to improve the speed of some requests, or
-  lower the priority of non-important requests. Using this setting without
-  prior experimentation can cause some major slowdown.
-
-http-request set-path <fmt> [ { if | unless } <condition> ]
-
-    This rewrites the request path with the result of the evaluation of format
-    string <fmt>. The query string, if any, is left intact. If a scheme and
-    authority is found before the path, they are left intact as well. If the
-    request doesn't have a path ("*"), this one is replaced with the format.
-    This can be used to prepend a directory component in front of a path for
-    example. See also "http-request set-query" and "http-request set-uri".
-
-    Example :
-      # prepend the host name before the path
-      http-request set-path /%[hdr(host)]%[path]
-
-http-request set-pathq <fmt> [ { if | unless } <condition> ]
-
-  This does the same as "http-request set-path" except that the query-string is
-  also rewritten. It may be used to remove the query-string, including the
-  question mark (it is not possible using "http-request set-query").
-
-http-request set-priority-class <expr> [ { if | unless } <condition> ]
-
-  This is used to set the queue priority class of the current request.
-  The value must be a sample expression which converts to an integer in the
-  range -2047..2047. Results outside this range will be truncated.
-  The priority class determines the order in which queued requests are
-  processed. Lower values have higher priority.
-
-http-request set-priority-offset <expr> [ { if | unless } <condition> ]
-
-  This is used to set the queue priority timestamp offset of the current
-  request. The value must be a sample expression which converts to an integer
-  in the range -524287..524287. Results outside this range will be truncated.
-  When a request is queued, it is ordered first by the priority class, then by
-  the current timestamp adjusted by the given offset in milliseconds. Lower
-  values have higher priority.
-  Note that the resulting timestamp is is only tracked with enough precision
-  for 524,287ms (8m44s287ms). If the request is queued long enough to where the
-  adjusted timestamp exceeds this value, it will be misidentified as highest
-  priority. Thus it is important to set "timeout queue" to a value, where when
-  combined with the offset, does not exceed this limit.
-
-http-request set-query <fmt> [ { if | unless } <condition> ]
-
-  This rewrites the request's query string which appears after the first
-  question mark ("?") with the result of the evaluation of format string <fmt>.
-  The part prior to the question mark is left intact. If the request doesn't
-  contain a question mark and the new value is not empty, then one is added at
-  the end of the URI, followed by the new value. If a question mark was
-  present, it will never be removed even if the value is empty. This can be
-  used to add or remove parameters from the query string.
-
-  See also "http-request set-query" and "http-request set-uri".
-
-  Example:
-    # replace "%3D" with "=" in the query string
-    http-request set-query %[query,regsub(%3D,=,g)]
-
-http-request set-src <expr> [ { if | unless } <condition> ]
-  This is used to set the source IP address to the value of specified
-  expression. Useful when a proxy in front of HAProxy rewrites source IP, but
-  provides the correct IP in a HTTP header; or you want to mask source IP for
-  privacy. All subsequent calls to "src" fetch will return this value
-  (see example).
-
-  Arguments :
-    <expr>  Is a standard HAProxy expression formed by a sample-fetch followed
-            by some converters.
-
-  See also "option forwardfor".
-
-  Example:
-    http-request set-src hdr(x-forwarded-for)
-    http-request set-src src,ipmask(24)
-
-    # After the masking this will track connections
-    # based on the IP address with the last byte zeroed out.
-    http-request track-sc0 src
-
-  When possible, set-src preserves the original source port as long as the
-  address family allows it, otherwise the source port is set to 0.
-
-http-request set-src-port <expr> [ { if | unless } <condition> ]
-
-  This is used to set the source port address to the value of specified
-  expression.
-
-  Arguments:
-    <expr>  Is a standard HAProxy expression formed by a sample-fetch followed
-            by some converters.
-
-  Example:
-    http-request set-src-port hdr(x-port)
-    http-request set-src-port int(4000)
-
-  When possible, set-src-port preserves the original source address as long as
-  the address family supports a port, otherwise it forces the source address to
-  IPv4 "0.0.0.0" before rewriting the port.
-
-http-request set-timeout { client | server | tunnel } { <timeout> | <expr> }
-                                       [ { if | unless } <condition> ]
-
-  This action overrides the specified "client", "server" or "tunnel" timeout for the
-  current stream only. The timeout can be specified in millisecond or with any
-  other unit if the number is suffixed by the unit as explained at the top of
-  this document. It is also possible to write an expression which must returns
-  a number interpreted as a timeout in millisecond.
-
-  Note that the server/tunnel timeouts are only relevant on the backend side
-  and thus this rule is only available for the proxies with backend
-  capabilities. As well as client timeout is only relevant for frontend side.
-  Also the timeout value must be non-null to obtain the expected results.
-
-  Example:
-    http-request set-timeout tunnel 5s
-    http-request set-timeout server req.hdr(host),map_int(host.lst)
-
-http-request set-tos <tos> [ { if | unless } <condition> ]
-
-  This is used to set the TOS or DSCP field value of packets sent to the client
-  to the value passed in <tos> on platforms which support this. This value
-  represents the whole 8 bits of the IP TOS field, and can be expressed both in
-  decimal or hexadecimal format (prefixed by "0x"). Note that only the 6 higher
-  bits are used in DSCP or TOS, and the two lower bits are always 0. This can
-  be used to adjust some routing behavior on border routers based on some
-  information from the request.
-
-  See RFC 2474, 2597, 3260 and 4594 for more information.
-
-http-request set-uri <fmt> [ { if | unless } <condition> ]
-
-  This rewrites the request URI with the result of the evaluation of format
-  string <fmt>. The scheme, authority, path and query string are all replaced
-  at once. This can be used to rewrite hosts in front of proxies, or to perform
-  complex modifications to the URI such as moving parts between the path and
-  the query string. If an absolute URI is set, it will be sent as is to
-  HTTP/1.1 servers. If it is not the desired behavior, the host, the path
-  and/or the query string should be set separately.
-  See also "http-request set-path" and "http-request set-query".
-
-http-request set-var(<var-name>[,<cond>...]) <expr> [ { if | unless } <condition> ]
-http-request set-var-fmt(<var-name>[,<cond>...]) <fmt> [ { if | unless } <condition> ]
-
-  This is used to set the contents of a variable. The variable is declared
-  inline.
-
-  Arguments:
-    <var-name>  The name of the variable starts with an indication about its
-                scope. The scopes allowed are:
-                  "proc" : the variable is shared with the whole process
-                  "sess" : the variable is shared with the whole session
-                  "txn"  : the variable is shared with the transaction
-                           (request and response)
-                  "req"  : the variable is shared only during request
-                           processing
-                  "res"  : the variable is shared only during response
-                           processing
-                This prefix is followed by a name. The separator is a '.'.
-                The name may only contain characters 'a-z', 'A-Z', '0-9'
-                and '_'.
-
-    <cond>      A set of conditions that must all be true for the variable to
-                actually be set (such as "ifnotempty", "ifgt" ...). See the
-                set-var converter's description for a full list of possible
-                conditions.
-
-    <expr>      Is a standard HAProxy expression formed by a sample-fetch
-                followed by some converters.
-
-    <fmt>       This is the value expressed using log-format rules (see Custom
-                Log Format in section 8.2.4).
-
-  Example:
-    http-request set-var(req.my_var) req.fhdr(user-agent),lower
-    http-request set-var-fmt(txn.from) %[src]:%[src_port]
-
-http-request silent-drop [ rst-ttl <ttl> ] [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and removes the client-facing
-  connection in a configurable way: When called without the rst-ttl argument,
-  we try to prevent sending any FIN or RST packet back to the client by
-  using TCP_REPAIR. If this fails (mainly because of missing privileges),
-  we fall back to sending a RST packet with a TTL of 1.
-
-  The effect is that the client still sees an established connection while
-  there is none on HAProxy, saving resources. However, stateful equipment
-  placed between the HAProxy and the client (firewalls, proxies,
-  load balancers) will also keep the established connection in their
-  session tables.
-
-  The optional rst-ttl changes this behaviour: TCP_REPAIR is not used,
-  and a RST packet with a configurable TTL is sent. When set to a
-  reasonable value, the RST packet travels through your own equipment,
-  deleting the connection in your middle-boxes, but does not arrive at
-  the client. Future packets from the client will then be dropped
-  already by your middle-boxes. These "local RST"s protect your resources,
-  but not the client's. Do not use it unless you fully understand how it works.
-
-http-request strict-mode { on | off } [ { if | unless } <condition> ]
-
-  This enables or disables the strict rewriting mode for following rules. It
-  does not affect rules declared before it and it is only applicable on rules
-  performing a rewrite on the requests. When the strict mode is enabled, any
-  rewrite failure triggers an internal error. Otherwise, such errors are
-  silently ignored. The purpose of the strict rewriting mode is to make some
-  rewrites optional while others must be performed to continue the request
-  processing.
-
-  By default, the strict rewriting mode is enabled. Its value is also reset
-  when a ruleset evaluation ends. So, for instance, if you change the mode on
-  the frontend, the default mode is restored when HAProxy starts the backend
-  rules evaluation.
-
-http-request tarpit [deny_status <status>] [ { if | unless } <condition> ]
-http-request tarpit [ { status | deny_status } <code>] [content-type <type>]
-          [ { default-errorfiles | errorfile <file> | errorfiles <name> |
-              file <file> | lf-file <file> | string <str> | lf-string <fmt> } ]
-          [ hdr <name> <fmt> ]*
-          [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and immediately blocks the request
-  without responding for a delay specified by "timeout tarpit" or
-  "timeout connect" if the former is not set. After that delay, if the client
-  is still connected, a response is returned so that the client does not
-  suspect it has been tarpitted. Logs will report the flags "PT". The goal of
-  the tarpit rule is to slow down robots during an attack when they're limited
-  on the number of concurrent requests. It can be very efficient against very
-  dumb robots, and will significantly reduce the load on firewalls compared to
-  a "deny" rule. But when facing "correctly" developed robots, it can make
-  things worse by forcing HAProxy and the front firewall to support insane
-  number of concurrent connections. By default an HTTP error 500 is returned.
-  But the response may be customized using same syntax than
-  "http-request return" rules. Thus, see "http-request return" for details.
-  For compatibility purpose, when no argument is defined, or only "deny_status",
-  the argument "default-errorfiles" is implied. It means
-  "http-request tarpit [deny_status <status>]" is an alias of
-  "http-request tarpit [status <status>] default-errorfiles".
-  No further "http-request" rules are evaluated.
-  See also "http-request return" and "http-request silent-drop".
-
-http-request track-sc0 <key> [table <table>] [ { if | unless } <condition> ]
-http-request track-sc1 <key> [table <table>] [ { if | unless } <condition> ]
-http-request track-sc2 <key> [table <table>] [ { if | unless } <condition> ]
-
-  This enables tracking of sticky counters from current request. These rules do
-  not stop evaluation and do not change default action. The number of counters
-  that may be simultaneously tracked by the same connection is set by the
-  global "tune.stick-counters" setting, which defaults to MAX_SESS_STKCTR if
-  set at build time (it is reported in haproxy -vv) and which defaults to 3,
-  so the track-sc number is between 0 and (tune.stick-counters-1). The first
-  "track-sc0" rule executed enables tracking of the counters of the specified
-  table as the first set. The first "track-sc1" rule executed enables tracking
-  of the counters of the specified table as the second set. The first
-  "track-sc2" rule executed enables tracking of the counters of the specified
-  table as the third set. It is a recommended practice to use the first set of
-  counters for the per-frontend counters and the second set for the per-backend
-  ones. But this is just a guideline, all may be used everywhere.
-
-  Arguments :
-    <key>   is mandatory, and is a sample expression rule as described in
-            section 7.3. It describes what elements of the incoming request or
-            connection will be analyzed, extracted, combined, and used to
-            select which table entry to update the counters.
-
-    <table> is an optional table to be used instead of the default one, which
-            is the stick-table declared in the current proxy. All the counters
-            for the matches and updates for the key will then be performed in
-            that table until the session ends.
-
-  Once a "track-sc*" rule is executed, the key is looked up in the table and if
-  it is not found, an entry is allocated for it. Then a pointer to that entry
-  is kept during all the session's life, and this entry's counters are updated
-  as often as possible, every time the session's counters are updated, and also
-  systematically when the session ends. Counters are only updated for events
-  that happen after the tracking has been started. As an exception, connection
-  counters and request counters are systematically updated so that they reflect
-  useful information.
-
-  If the entry tracks concurrent connection counters, one connection is counted
-  for as long as the entry is tracked, and the entry will not expire during
-  that time. Tracking counters also provides a performance advantage over just
-  checking the keys, because only one table lookup is performed for all ACL
-  checks that make use of it.
-
-http-request unset-var(<var-name>) [ { if | unless } <condition> ]
-
-  This is used to unset a variable. See above for details about <var-name>.
-
-  Example:
-    http-request unset-var(req.my_var)
-
-http-request use-service <service-name> [ { if | unless } <condition> ]
-
-  This directive executes the configured HTTP service to reply to the request
-  and stops the evaluation of the rules. An HTTP service may choose to reply by
-  sending any valid HTTP response or it may immediately close the connection
-  without sending any response. Outside natives services, for instance the
-  Prometheus exporter, it is possible to write your own services in Lua. No
-  further "http-request" rules are evaluated.
-
-  Arguments :
-    <service-name>  is mandatory. It is the service to call
-
-  Example:
-    http-request use-service prometheus-exporter if { path /metrics }
-
-http-request wait-for-body time <time> [ at-least <bytes> ]
-             [ { if | unless } <condition> ]
-
-  This will delay the processing of the request waiting for the payload for at
-  most <time> milliseconds. if "at-least" argument is specified, HAProxy stops
-  to wait the payload when the first <bytes> bytes are received. 0 means no
-  limit, it is the default value. Regardless the "at-least" argument value,
-  HAProxy stops to wait if the whole payload is received or if the request
-  buffer is full.  This action may be used as a replacement to "option
-  http-buffer-request".
-
-  Arguments :
-
-    <time>    is mandatory. It is the maximum time to wait for the body. It
-              follows the HAProxy time format and is expressed in milliseconds.
-
-    <bytes>   is optional. It is the minimum payload size to receive to stop to
-              wait. It follows the HAProxy size format and is expressed in
-              bytes.
-
-  Example:
-    http-request wait-for-body time 1s at-least 1k if METH_POST
-
-  See also : "option http-buffer-request"
-
-http-request wait-for-handshake [ { if | unless } <condition> ]
-
-  This will delay the processing of the request until the SSL handshake
-  happened. This is mostly useful to delay processing early data until we're
-  sure they are valid.
-
-
 http-response <action> <options...> [ { if | unless } <condition> ]
   Access control for Layer 7 responses
 
@@ -8204,55 +6917,24 @@ http-response <action> <options...> [ { if | unless } <condition> ]
 
   The http-response statement defines a set of rules which apply to layer 7
   processing. The rules are evaluated in their declaration order when they are
-  met in a frontend, listen or backend section. Any rule may optionally be
-  followed by an ACL-based condition, in which case it will only be evaluated
-  if the condition is true. Since these rules apply on responses, the backend
-  rules are applied first, followed by the frontend's rules.
+  met in a frontend, listen or backend section. Since these rules apply on
+  responses, the backend rules are applied first, followed by the frontend's
+  rules. Any rule may optionally be followed by an ACL-based condition, in
+  which case it will only be evaluated if the condition evaluates to true.
 
-  The first keyword is the rule's action. Several types of actions are
-  supported:
-    - add-acl(<file-name>) <key fmt>
-    - add-header <name> <fmt>
-    - allow
-    - cache-store <name>
-    - capture <sample> id <id>
-    - del-acl(<file-name>) <key fmt>
-    - del-header <name> [ -m <meth> ]
-    - del-map(<file-name>) <key fmt>
-    - deny [ { status | deny_status } <code>] ...
-    - redirect <rule>
-    - replace-header <name> <regex-match> <replace-fmt>
-    - replace-value <name> <regex-match> <replace-fmt>
-    - return [status <code>] [content-type <type>] ...
-    - sc-add-gpc(<idx>,<sc-id>) { <int> | <expr> }
-    - sc-inc-gpc(<idx>,<sc-id>)
-    - sc-inc-gpc0(<sc-id>)
-    - sc-inc-gpc1(<sc-id>)
-    - sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
-    - sc-set-gpt0(<sc-id>) { <int> | <expr> }
-    - send-spoe-group <engine-name> <group-name>
-    - set-bandwidth-limit <name> [limit {<expr> | <size>}] [period {<expr> | <time>}]
-    - set-header <name> <fmt>
-    - set-log-level <level>
-    - set-map(<file-name>) <key fmt> <value fmt>
-    - set-mark <mark>
-    - set-nice <nice>
-    - set-status <status> [reason <str>]
-    - set-timeout { client | server | tunnel } { <timeout> | <expr> }
-    - set-tos <tos>
-    - set-var(<var-name>[,<cond>...]) <expr>
-    - set-var-fmt(<var-name>[,<cond>...]) <fmt>
-    - silent-drop [ rst-ttl <ttl> ]
-    - strict-mode { on | off }
-    - track-sc0 <key> [table <table>]
-    - track-sc1 <key> [table <table>]
-    - track-sc2 <key> [table <table>]
-    - unset-var(<var-name>)
-    - wait-for-body time <time> [ at-least <bytes> ]
+  The condition is evaluated just before the action is executed, and the action
+  is performed exactly once. As such, there is no problem if an action changes
+  an element which is checked as part of the condition. This also means that
+  multiple actions may rely on the same condition so that the first action that
+  changes the condition's evaluation is sufficient to implicitly disable the
+  remaining actions. This is used for example when trying to assign a value to
+  a variable from various sources when it's empty. There is no limit to the
+  number of "http-response" statements per instance.
 
-  The supported actions are described below.
-
-  There is no limit to the number of http-response statements per instance.
+  The first keyword after "http-response" in the syntax is the rule's action,
+  optionally followed by a varying number of arguments for the action. The
+  supported actions and their respective syntaxes are enumerated in section 4.3
+  "Actions" (look for actions which tick "HTTP Res").
 
   This directive is only available from named defaults sections, not anonymous
   ones. Rules defined in the defaults section are evaluated before ones in the
@@ -8280,274 +6962,6 @@ http-response <action> <options...> [ { if | unless } <condition> ]
   See also : "http-request", section 3.4 about userlists and section 7 about
              ACL usage.
 
-http-response add-acl(<file-name>) <key fmt> [ { if | unless } <condition> ]
-
-  This is used to add a new entry into an ACL. Please refer to "http-request
-  add-acl" for a complete description.
-
-http-response add-header <name> <fmt> [ { if | unless } <condition> ]
-
-  This appends an HTTP header field whose name is specified in <name> and whose
-  value is defined by <fmt>. Please refer to "http-request add-header" for a
-  complete description.
-
-http-response allow [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and lets the response pass the check.
-  No further "http-response" rules are evaluated for the current section.
-
-http-response cache-store <name> [ { if | unless } <condition> ]
-
-  See section 6.2 about cache setup.
-
-http-response capture <sample> id <id> [ { if | unless } <condition> ]
-
-  This captures sample expression <sample> from the response buffer, and
-  converts it to a string. The resulting string is stored into the next
-  response "capture" slot, so it will possibly appear next to some captured
-  HTTP headers. It will then automatically appear in the logs, and it will be
-  possible to extract it using sample fetch rules to feed it into headers or
-  anything. Please check section 7.3 (Fetching samples) and "capture response
-  header" for more information.
-
-  The keyword "id" is the id of the capture slot which is used for storing the
-  string. The capture slot must be defined in an associated frontend.
-  This is useful to run captures in backends. The slot id can be declared by a
-  previous directive "http-response capture" or with the "declare capture"
-  keyword.
-
-  When using this action in a backend, double check that the relevant
-  frontend(s) have the required capture slots otherwise, this rule will be
-  ignored at run time. This can't be detected at configuration parsing time
-  due to HAProxy's ability to dynamically resolve backend name at runtime.
-
-http-response del-acl(<file-name>) <key fmt> [ { if | unless } <condition> ]
-
-  This is used to delete an entry from an ACL. Please refer to "http-request
-  del-acl" for a complete description.
-
-http-response del-header <name> [ -m <meth> ] [ { if | unless } <condition> ]
-
-  This removes all HTTP header fields whose name is specified in <name>. Please
-  refer to "http-request del-header" for a complete description.
-
-http-response del-map(<file-name>) <key fmt> [ { if | unless } <condition> ]
-
-  This is used to delete an entry from a MAP. Please refer to "http-request
-  del-map" for a complete description.
-
-http-response deny [deny_status <status>] [ { if | unless } <condition> ]
-http-response deny [ { status | deny_status } <code>] [content-type <type>]
-          [ { default-errorfiles | errorfile <file> | errorfiles <name> |
-              file <file> | lf-file <file> | string <str> | lf-string <fmt> } ]
-          [ hdr <name> <fmt> ]*
-          [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and immediately rejects the response.
-  By default an HTTP 502 error is returned. But the response may be customized
-  using same syntax than "http-response return" rules. Thus, see
-  "http-response return" for details. For compatibility purpose, when no
-  argument is defined, or only "deny_status", the argument "default-errorfiles"
-  is implied. It means "http-response deny [deny_status <status>]" is an alias
-  of "http-response deny [status <status>] default-errorfiles".
-  No further "http-response" rules are evaluated.
-  See also "http-response return".
-
-http-response redirect <rule> [ { if | unless } <condition> ]
-
-  This performs an HTTP redirection based on a redirect rule.
-  This supports a format string similarly to "http-request redirect" rules,
-  with the exception that only the "location" type of redirect is possible on
-  the response. See the "redirect" keyword for the rule's syntax. When a
-  redirect rule is applied during a response, connections to the server are
-  closed so that no data can be forwarded from the server to the client.
-
-http-response replace-header <name> <regex-match> <replace-fmt>
-                             [ { if | unless } <condition> ]
-
-  This works like "http-request replace-header" except that it works on the
-  server's response instead of the client's request.
-
-  Example:
-    http-response replace-header Set-Cookie (C=[^;]*);(.*) \1;ip=%bi;\2
-
-    # applied to:
-    Set-Cookie: C=1; expires=Tue, 14-Jun-2016 01:40:45 GMT
-
-    # outputs:
-    Set-Cookie: C=1;ip=192.168.1.20; expires=Tue, 14-Jun-2016 01:40:45 GMT
-
-    # assuming the backend IP is 192.168.1.20.
-
-http-response replace-value <name> <regex-match> <replace-fmt>
-                            [ { if | unless } <condition> ]
-
-  This works like "http-request replace-value" except that it works on the
-  server's response instead of the client's request.
-
-  Example:
-    http-response replace-value Cache-control ^public$ private
-
-    # applied to:
-    Cache-Control: max-age=3600, public
-
-    # outputs:
-    Cache-Control: max-age=3600, private
-
-http-response return [status <code>] [content-type <type>]
-          [ { default-errorfiles | errorfile <file> | errorfiles <name> |
-              file <file> | lf-file <file> | string <str> | lf-string <fmt> } ]
-          [ hdr <name> <value> ]*
-          [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and immediately returns a
-  response. Please refer to "http-request return" for a complete
-  description. No further "http-response" rules are evaluated.
-
-http-response sc-add-gpc(<idx>,<sc-id>) { <int> | <expr> }
-                                           [ { if | unless } <condition> ]
-
-  This action increments the General Purpose Counter according to the sticky
-  counter designated by <sc-id>. Please refer to "http-request sc-add-gpc" for
-  a complete description.
-
-http-response sc-inc-gpc(<idx>,<sc-id>) [ { if | unless } <condition> ]
-http-response sc-inc-gpc0(<sc-id>) [ { if | unless } <condition> ]
-http-response sc-inc-gpc1(<sc-id>) [ { if | unless } <condition> ]
-
-  These actions increment the General Purppose Counters according to the sticky
-  counter designated by <sc-id>. Please refer to "http-request sc-inc-gpc",
-  "http-request sc-inc-gpc0" and "http-request sc-inc-gpc1" for a complete
-  description.
-
-http-response sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
-                                        [ { if | unless } <condition> ]
-http-response sc-set-gpt0(<sc-id>) { <int> | <expr> }
-                                   [ { if | unless } <condition> ]
-
-  These actions set the 32-bit unsigned General Purpose Tags according to the
-  sticky counter designated by <sc-id>. Please refer to "http-request
-  sc-set-gpt" and "http-request sc-set-gpt0" for a complete description.
-
-http-response send-spoe-group <engine-name> <group-name>
-                              [ { if | unless } <condition> ]
-
-  This action is used to trigger sending of a group of SPOE messages. Please
-  refer to "http-request send-spoe-group" for a complete description.
-
-http-response set-bandwidth-limit <name> [limit { <expr> | <size> }]
-                 [period { <expr> | <time> }] [ { if | unless } <condition> ]
-
-  This action is used to enable the bandwidth limitation filter <name>, either
-  on the upload or download direction depending on the filter type. Please
-  refer to "http-request set-bandwidth-limit" for a complete description.
-
-http-response set-header <name> <fmt> [ { if | unless } <condition> ]
-
-  This does the same as "http-response add-header" except that the header name
-  is first removed if it existed. This is useful when passing security
-  information to the server, where the header must not be manipulated by
-  external users.
-
-http-response set-log-level <level> [ { if | unless } <condition> ]
-
-  This is used to change the log level of the current response. Please refer to
-  "http-request set-log-level" for a complete description.
-
-http-response set-map(<file-name>) <key fmt> <value fmt>
-
-  This is used to add a new entry into a MAP. Please refer to "http-request
-  set-map" for a complete description.
-
-http-response set-mark <mark> [ { if | unless } <condition> ]
-
-  This action is used to set the Netfilter/IPFW MARK in all packets sent to the
-  client to the value passed in <mark> on platforms which support it. Please
-  refer to "http-request set-mark" for a complete description.
-
-http-response set-nice <nice> [ { if | unless } <condition> ]
-
-  This sets the "nice" factor of the current request being processed. Please
-  refer to "http-request set-nice" for a complete description.
-
-http-response set-status <status> [reason <str>]
-                         [ { if | unless } <condition> ]
-
-  This replaces the response status code with <status> which must be an integer
-  between 100 and 999. Optionally, a custom reason text can be provided defined
-  by <str>, or the default reason for the specified code will be used as a
-  fallback.
-
-  Example:
-    # return "431 Request Header Fields Too Large"
-    http-response set-status 431
-    # return "503 Slow Down", custom reason
-    http-response set-status 503 reason "Slow Down".
-
-http-response set-timeout { client | server | tunnel } { <timeout> | <expr> }
-                                       [ { if | unless } <condition> ]
-
-  This action overrides the specified "client", "server" or "tunnel" timeout for the
-  current stream only. The timeout can be specified in millisecond or with any
-  other unit if the number is suffixed by the unit as explained at the top of
-  this document. It is also possible to write an expression which must returns
-  a number interpreted as a timeout in millisecond.
-
-  Note that the server/tunnel timeouts are only relevant on the backend side
-  and thus this rule is only available for the proxies with backend
-  capabilities. As well as client timeout is only relevant for frontend side.
-  Also the timeout value must be non-null to obtain the expected results.
-
-  Example:
-    http-response set-timeout tunnel 5s
-    http-response set-timeout server res.hdr(X-Refresh-Seconds),mul(1000)
-
-http-response set-tos <tos> [ { if | unless } <condition> ]
-
-  This is used to set the TOS or DSCP field value of packets sent to the client
-  to the value passed in <tos> on platforms which support this. Please refer to
-  "http-request set-tos" for a complete description.
-
-http-response set-var(<var-name>[,<cond>...]) <expr> [ { if | unless } <condition> ]
-http-response set-var-fmt(<var-name>[,<cond>...]) <fmt> [ { if | unless } <condition> ]
-
-  This is used to set the contents of a variable. The variable is declared
-  inline. Please refer to "http-request set-var" and "http-request set-var-fmt"
-  for a complete description.
-
-http-response silent-drop [ rst-ttl <ttl> ] [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and makes the client-facing connection
-  suddenly disappear using a system-dependent way that tries to prevent the
-  client from being notified. Please refer to "http-request silent-drop" for a
-  complete description.
-
-http-response strict-mode { on | off }  [ { if | unless } <condition> ]
-
-  This enables or disables the strict rewriting mode for following
-  rules. Please refer to "http-request strict-mode" for a complete description.
-
-http-response track-sc0 <key> [table <table>] [ { if | unless } <condition> ]
-http-response track-sc1 <key> [table <table>] [ { if | unless } <condition> ]
-http-response track-sc2 <key> [table <table>] [ { if | unless } <condition> ]
-
-  This enables tracking of sticky counters from current connection. Please
-  refer to "http-request track-sc0", "http-request track-sc1" and "http-request
-  track-sc2" for a complete description.
-
-http-response unset-var(<var-name>) [ { if | unless } <condition> ]
-
-  This is used to unset a variable. See "http-request set-var" for details
-  about <var-name>.
-
-http-response wait-for-body time <time> [ at-least <bytes> ]
-             [ { if | unless } <condition> ]
-
-  This will delay the processing of the response waiting for the payload for at
-  most <time> milliseconds. Please refer to "http-request wait-for-body" for a
-  complete description.
-
-
 http-reuse { never | safe | aggressive | always }
   Declare how idle HTTP connections may be shared between requests
 
@@ -13339,38 +11753,20 @@ tcp-request connection <action> <options...> [ { if | unless } <condition> ]
   accept the incoming connection. There is no specific limit to the number of
   rules which may be inserted. Any rule may optionally be followed by an
   ACL-based condition, in which case it will only be evaluated if the condition
-  is true.
+  evaluates to true.
 
-  The first keyword is the rule's action. Several types of actions are
-  supported:
-    - accept
-    - expect-netscaler-cip layer4
-    - expect-proxy layer4
-    - reject
-    - sc-add-gpc(<idx>,<sc-id>) { <int> | <expr> }
-    - sc-inc-gpc(<idx>,<sc-id>)
-    - sc-inc-gpc0(<sc-id>)
-    - sc-inc-gpc1(<sc-id>)
-    - sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
-    - sc-set-gpt0(<sc-id>) { <int> | <expr> }
-    - set-dst <expr>
-    - set-dst-port <expr>
-    - set-mark <mark>
-    - set-src <expr>
-    - set-src-port <expr>
-    - set-tos <tos>
-    - set-var(<var-name>[,<cond>...]) <expr>
-    - set-var-fmt(<var-name>[,<cond>...]) <fmt>
-    - silent-drop [ rst-ttl <ttl> ]
-    - track-sc0 <key> [table <table>]
-    - track-sc1 <key> [table <table>]
-    - track-sc2 <key> [table <table>]
-    - unset-var(<var-name>)
+  The condition is evaluated just before the action is executed, and the action
+  is performed exactly once. As such, there is no problem if an action changes
+  an element which is checked as part of the condition. This also means that
+  multiple actions may rely on the same condition so that the first action that
+  changes the condition's evaluation is sufficient to implicitly disable the
+  remaining actions. This is used for example when trying to assign a value to
+  a variable from various sources when it's empty.
 
-  The supported actions are described below.
-
-  There is no limit to the number of "tcp-request connection" statements per
-  instance.
+  The first keyword after "tcp-request connection" in the syntax is the rule's
+  action, optionally followed by a varying number of arguments for the action.
+  The supported actions and their respective syntaxes are enumerated in
+  section 4.3 "Actions" (look for actions which tick "TCP RqCon").
 
   This directive is only available from named defaults sections, not anonymous
   ones. Rules defined in the defaults section are evaluated before ones in the
@@ -13407,125 +11803,6 @@ tcp-request connection <action> <options...> [ { if | unless } <condition> ]
 
   See also : "tcp-request session", "tcp-request content", "stick-table"
 
-tcp-request connection accept [ { if | unless } <condition> ]
-
-  This is used to accept the connection. No further "tcp-request connection"
-  rules are evaluated.
-
-tcp-request connection expect-netscaler-cip layer4
-                       [ { if | unless } <condition> ]
-
-  This configures the client-facing connection to receive a NetScaler Client IP
-  insertion protocol header before any byte is read from the socket.  This is
-  equivalent to having the "accept-netscaler-cip" keyword on the "bind" line,
-  except that using the TCP rule allows the PROXY protocol to be accepted only
-  for certain IP address ranges using an ACL. This is convenient when multiple
-  layers of load balancers are passed through by traffic coming from public
-  hosts.
-
-tcp-request connection expect-proxy layer4 [ { if | unless } <condition> ]
-
-  This configures the client-facing connection to receive a PROXY protocol
-  header before any byte is read from the socket. This is equivalent to having
-  the "accept-proxy" keyword on the "bind" line, except that using the TCP rule
-  allows the PROXY protocol to be accepted only for certain IP address ranges
-  using an ACL. This is convenient when multiple layers of load balancers are
-  passed through by traffic coming from public hosts.
-
-tcp-request connection reject [ { if | unless } <condition> ]
-
-  This is used to reject the connection. No further "tcp-request connection"
-  rules are evaluated. Rejected connections do not even become a session, which
-  is why they are accounted separately for in the stats, as "denied
-  connections". They are not considered for the session rate-limit and are not
-  logged either. The reason is that these rules should only be used to filter
-  extremely high connection rates such as the ones encountered during a massive
-  DDoS attack. Under these extreme conditions, the simple action of logging
-  each event would make the system collapse and would considerably lower the
-  filtering capacity. If logging is absolutely desired, then "tcp-request
-  content" rules should be used instead, as "tcp-request session" rules will
-  not log either.
-
-tcp-request connection sc-add-gpc(<idx>,<sc-id>) { <int> | <expr> }
-                                           [ { if | unless } <condition> ]
-
-  This action increments the General Purpose Counter according to the sticky
-  counter designated by <sc-id>. Please refer to "http-request sc-add-gpc" for
-  a complete description.
-
-tcp-request connection sc-inc-gpc(<idx>,<sc-id>) [ { if | unless } <condition> ]
-tcp-request connection sc-inc-gpc0(<sc-id>) [ { if | unless } <condition> ]
-tcp-request connection sc-inc-gpc1(<sc-id>) [ { if | unless } <condition> ]
-
-  These actions increment the General Purppose Counters according to the sticky
-  counter designated by <sc-id>. Please refer to "http-request sc-inc-gpc",
-  "http-request sc-inc-gpc0" and "http-request sc-inc-gpc1" for a complete
-  description.
-
-tcp-request connection sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
-                       [ { if | unless } <condition> ]
-tcp-request connection sc-set-gpt0(<sc-id>) { <int> | <expr> }
-                       [ { if | unless } <condition> ]
-
-  These actions set the 32-bit unsigned General Purpose Tags according to the
-  sticky counter designated by <sc-id>. Please refer to "http-request
-  sc-set-gpt" and "http-request sc-set-gpt0" for a complete description.
-
-tcp-request connection set-dst <expr> [ { if | unless } <condition> ]
-tcp-request connection set-dst-port <expr> [ { if | unless } <condition> ]
-
-  These actions are used to set the destination IP/Port address to the value of
-  specified expression. Please refer to "http-request set-dst" and
-  "http-request set-dst-port" for a complete description.
-
-tcp-request connection set-mark <mark> [ { if | unless } <condition> ]
-
-  This action is used to set the Netfilter/IPFW MARK in all packets sent to the
-  client to the value passed in <mark> on platforms which support it. Please
-  refer to "http-request set-mark" for a complete description.
-
-tcp-request connection set-src <expr> [ { if | unless } <condition> ]
-tcp-request connection set-src-port <expr> [ { if | unless } <condition> ]
-
-  These actions are used to set the source IP/Port address to the value of
-  specified expression. Please refer to "http-request set-src" and
-  "http-request set-src-port" for a complete description.
-
-tcp-request connection set-tos <tos> [ { if | unless } <condition> ]
-
-  This is used to set the TOS or DSCP field value of packets sent to the client
-  to the value passed in <tos> on platforms which support this. Please refer to
-  "http-request set-tos" for a complete description.
-
-tcp-request connection set-var(<var-name>[,<cond>...]) <expr> [ { if | unless } <condition> ]
-tcp-request connection set-var-fmt(<var-name>[,<cond>...]) <fmt> [ { if | unless } <condition> ]
-
-  This is used to set the contents of a variable. The variable is declared
-  inline. "tcp-request connection" can set variables in the "proc" and "sess"
-  scopes. Please refer to "http-request set-var" and "http-request set-var-fmt"
-  for a complete description.
-
-tcp-request connection silent-drop [ rst-ttl <ttl> ] [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and makes the client-facing connection
-  suddenly disappear using a system-dependent way that tries to prevent the
-  client from being notified. Please refer to "http-request silent-drop" for a
-  complete description.
-
-tcp-request connection track-sc0 <key> [table <table>] [ { if | unless } <condition> ]
-tcp-request connection track-sc1 <key> [table <table>] [ { if | unless } <condition> ]
-tcp-request connection track-sc2  <key> [table <table>] [ { if | unless } <condition> ]
-
-  This enables tracking of sticky counters from current connection. Please
-  refer to "http-request track-sc0", "http-request track-sc1" and "http-request
-  track-sc2" for a complete description.
-
-tcp-request connection unset-var(<var-name>) [ { if | unless } <condition> ]
-
-  This is used to unset a variable. Please refer to "http-request set-var" for
-  details about variables.
-
-
 tcp-request content <action> [{if | unless} <condition>]
   Perform an action on a new session depending on a layer 4-7 condition
   May be used in sections :   defaults | frontend | listen | backend
@@ -13560,42 +11837,6 @@ tcp-request content <action> [{if | unless} <condition>]
   contents. There is no specific limit to the number of rules which may be
   inserted.
 
-  The first keyword is the rule's action. Several types of actions are
-  supported:
-    - accept
-    - capture <sample> len <length>
-    - do-resolve(<var>,<resolvers>,[ipv4,ipv6]) <expr>
-    - reject
-    - sc-add-gpc(<idx>,<sc-id>) { <int> | <expr> }
-    - sc-inc-gpc(<idx>,<sc-id>)
-    - sc-inc-gpc0(<sc-id>)
-    - sc-inc-gpc1(<sc-id>)
-    - sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
-    - sc-set-gpt0(<sc-id>) { <int> | <expr> }
-    - send-spoe-group <engine-name> <group-name>
-    - set-bandwidth-limit <name> [limit {<expr> | <size>}] [period {<expr> | <time>}]
-    - set-dst <expr>
-    - set-dst-port <expr>
-    - set-log-level <level>
-    - set-mark <mark>
-    - set-nice <nice>
-    - set-priority-class <expr>
-    - set-priority-offset <expr>
-    - set-src <expr>
-    - set-src-port <expr>
-    - set-tos <tos>
-    - set-var(<var-name>[,<cond>...]) <expr>
-    - set-var-fmt(<var-name>[,<cond>...]) <fmt>
-    - silent-drop [ rst-ttl <ttl> ]
-    - switch-mode http [ proto <name> ]
-    - track-sc0 <key> [table <table>]
-    - track-sc1 <key> [table <table>]
-    - track-sc2 <key> [table <table>]
-    - unset-var(<var-name>)
-    - use-service <service-name>
-
-  The supported actions are described below.
-
   While there is nothing mandatory about it, it is recommended to use the
   track-sc0 in "tcp-request connection" rules, track-sc1 for "tcp-request
   content" rules in the frontend, and track-sc2 for "tcp-request content"
@@ -13603,6 +11844,11 @@ tcp-request content <action> [{if | unless} <condition>]
   and easier to troubleshoot, but this is just a guideline and all counters
   may be used everywhere.
 
+  The first keyword after "tcp-request content" in the syntax is the rule's
+  action, optionally followed by a varying number of arguments for the action.
+  The supported actions and their respective syntaxes are enumerated in
+  section 4.3 "Actions" (look for actions which tick "TCP RqCnt").
+
   This directive is only available from named defaults sections, not anonymous
   ones. Rules defined in the defaults section are evaluated before ones in the
   associated proxy section. To avoid ambiguities, in this case the same
@@ -13642,7 +11888,6 @@ tcp-request content <action> [{if | unless} <condition>]
     tcp-request content use-service lua.deny if { src -f /etc/haproxy/blacklist.lst }
 
   Example:
-
         tcp-request content set-var(sess.my_var) src
         tcp-request content set-var-fmt(sess.from) %[src]:%[src_port]
         tcp-request content unset-var(sess.my_var2)
@@ -13714,172 +11959,6 @@ tcp-request content <action> [{if | unless} <condition>]
   See also : "tcp-request connection", "tcp-request session",
              "tcp-request inspect-delay", and "http-request".
 
-tcp-request content accept [ { if | unless } <condition> ]
-
-  This is used to accept the connection. No further "tcp-request content"
-  rules are evaluated for the current section.
-
-tcp-request content capture <sample> len <length>
-                    [ { if | unless } <condition> ]
-
-  This captures sample expression <sample> from the request buffer, and
-  converts it to a string of at most <len> characters. The resulting string is
-  stored into the next request "capture" slot, so it will possibly appear next
-  to some captured HTTP headers. It will then automatically appear in the logs,
-  and it will be possible to extract it using sample fetch rules to feed it
-  into headers or anything. The length should be limited given that this size
-  will be allocated for each capture during the whole session life. Please
-  check section 7.3 (Fetching samples) and "capture request header" for more
-  information.
-
-tcp-request content do-resolve(<var>,<resolvers>,[ipv4,ipv6]) <expr>
-
-  This action performs a DNS resolution of the output of <expr> and stores the
-  result in the variable <var>. Please refer to "http-request do-resolve" for a
-  complete description.
-
-tcp-request content reject [ { if | unless } <condition> ]
-
-  This is used to reject the connection. No further "tcp-request content" rules
-  are evaluated.
-
-tcp-request content sc-add-gpc(<idx>,<sc-id>) { <int> | <expr> }
-                                           [ { if | unless } <condition> ]
-
-  This action increments the General Purpose Counter according to the sticky
-  counter designated by <sc-id>. Please refer to "http-request sc-add-gpc" for
-  a complete description.
-
-tcp-request content sc-inc-gpc(<idx>,<sc-id>) [ { if | unless } <condition> ]
-tcp-request content sc-inc-gpc0(<sc-id>) [ { if | unless } <condition> ]
-tcp-request content sc-inc-gpc1(<sc-id>) [ { if | unless } <condition> ]
-
-  These actions increment the General Purppose Counters according to the sticky
-  counter designated by <sc-id>. Please refer to "http-request sc-inc-gpc",
-  "http-request sc-inc-gpc0" and "http-request sc-inc-gpc1" for a complete
-  description.
-
-tcp-request content sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
-                    [ { if | unless } <condition> ]
-tcp-request content sc-set-gpt0(<sc-id>) { <int> | <expr> }
-                    [ { if | unless } <condition> ]
-
-  These actions set the 32-bit unsigned General Purpose Tags according to the
-  sticky counter designated by <sc-id>. Please refer to "http-request
-  sc-set-gpt" and "http-request sc-set-gpt0" for a complete description.
-
-tcp-request content send-spoe-group <engine-name> <group-name>
-                    [ { if | unless } <condition> ]
-
-  This action is is used to trigger sending of a group of SPOE messages. Please
-  refer to "http-request send-spoe-group" for a complete description.
-
-tcp-request content set-bandwidth-limit <name> [limit { <expr> | <size> }]
-                 [period { <expr> | <time> }] [ { if | unless } <condition> ]
-
-  This action is used to enable the bandwidth limitation filter <name>, either
-  on the upload or download direction depending on the filter type. Please
-  refer to "http-request set-bandwidth-limit" for a complete description.
-
-tcp-request content set-dst <expr> [ { if | unless } <condition> ]
-tcp-request content set-dst-port <expr> [ { if | unless } <condition> ]
-
-  These actions are used to set the destination IP/Port address to the value of
-  specified expression. Please refer to "http-request set-dst" and
-  "http-request set-dst-port" for a complete description.
-
-tcp-request content set-log-level <level>  [ { if | unless } <condition> ]
-
-  This action is used to set the log level of the current session. Please refer
-  to "http-request set-log-level". for a complete description.
-
-tcp-request content set-mark <mark> [ { if | unless } <condition> ]
-
-  This action is used to set the Netfilter/IPFW MARK in all packets sent to the
-  client to the value passed in <mark> on platforms which support it. Please
-  refer to "http-request set-mark" for a complete description.
-
-tcp-request content set-nice <nice> [ { if | unless } <condition> ]
-
-  This sets the "nice" factor of the current request being processed. Please
-  refer to "http-request set-nice" for a complete description.
-
-tcp-request content set-priority-class <expr> [ { if | unless } <condition> ]
-
-  This is used to set the queue priority class of the current request. Please
-  refer to "http-request set-priority-class" for a complete description.
-
-tcp-request content set-priority-offset <expr> [ { if | unless } <condition> ]
-
-  This is used to set the queue priority timestamp offset of the current
-  request. Please refer to "http-request set-priority-offset" for a complete
-  description.
-
-tcp-request content set-src <expr> [ { if | unless } <condition> ]
-tcp-request content set-src-port <expr> [ { if | unless } <condition> ]
-
-  These actions are used to set the source IP/Port address to the value of
-  specified expression. Please refer to "http-request set-src" and
-  "http-request set-src-port" for a complete description.
-
-tcp-request content set-tos <tos> [ { if | unless } <condition> ]
-
-  This is used to set the TOS or DSCP field value of packets sent to the client
-  to the value passed in <tos> on platforms which support this. Please refer to
-  "http-request set-tos" for a complete description.
-
-tcp-request content set-var(<var-name>[,<cond>...]) <expr> [ { if | unless } <condition> ]
-tcp-request content set-var-fmt(<var-name>[,<cond>...]) <fmt> [ { if | unless } <condition> ]
-
-  This is used to set the contents of a variable. The variable is declared
-  inline. Please refer to "http-request set-var" and "http-request set-var-fmt"
-  for a complete description.
-
-tcp-request content silent-drop [ rst-ttl <ttl> ] [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and makes the client-facing connection
-  suddenly disappear using a system-dependent way that tries to prevent the
-  client from being notified. Please refer to "http-request silent-drop" for a
-  complete description.
-
-tcp-request content switch-mode http [ proto <name> ]
-                    [ { if | unless } <condition> ]
-
-  This action is used to perform a connection upgrade. Only HTTP upgrades are
-  supported for now. The protocol may optionally be specified. This action is
-  only available for a proxy with the frontend capability. The connection
-  upgrade is immediately performed, following "tcp-request content" rules are
-  not evaluated. This upgrade method should be preferred to the implicit one
-  consisting to rely on the backend mode. When used, it is possible to set HTTP
-  directives in a frontend without any warning. These directives will be
-  conditionally evaluated if the HTTP upgrade is performed. However, an HTTP
-  backend must still be selected. It remains unsupported to route an HTTP
-  connection (upgraded or not) to a TCP server.
-
-  See section 4 about Proxies for more details on HTTP upgrades.
-
-tcp-request content track-sc0 <key> [table <table>] [ { if | unless } <condition> ]
-tcp-request content track-sc1 <key> [table <table>] [ { if | unless } <condition> ]
-tcp-request content track-sc2  <key> [table <table>] [ { if | unless } <condition> ]
-
-  This enables tracking of sticky counters from current connection. Please
-  refer to "http-request track-sc0", "http-request track-sc1" and "http-request
-  track-sc2" for a complete description.
-
-tcp-request content unset-var(<var-name>) [ { if | unless } <condition> ]
-
-  This is used to unset a variable. Please refer to "http-request set-var" for
-  details about variables.
-
-tcp-request content use-service <service-name> [ { if | unless } <condition> ]
-
-  This action is used to executes a TCP service which will reply to the request
-  and stop the evaluation of the rules. This service may choose to reply by
-  sending any valid response or it may immediately close the connection without
-  sending anything. Outside natives services, it is possible to write your own
-  services in Lua. No further "tcp-request content" rules are evaluated.
-
-
 tcp-request inspect-delay <timeout>
   Set the maximum allowed time to wait for data during content inspection
   May be used in sections :   defaults | frontend | listen | backend
@@ -13969,32 +12048,10 @@ tcp-request session <action> [{if | unless} <condition>]
   accept the incoming session. There is no specific limit to the number of
   rules which may be inserted.
 
-  The first keyword is the rule's action. Several types of actions are
-  supported:
-    - accept
-    - attach-srv <srv> [name <expr>]
-    - reject
-    - sc-add-gpc(<idx>,<sc-id>) { <int> | <expr> }
-    - sc-inc-gpc(<idx>,<sc-id>)
-    - sc-inc-gpc0(<sc-id>)
-    - sc-inc-gpc1(<sc-id>)
-    - sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
-    - sc-set-gpt0(<sc-id>) { <int> | <expr> }
-    - set-dst <expr>
-    - set-dst-port <expr>
-    - set-mark <mark>
-    - set-src <expr>
-    - set-src-port <expr>
-    - set-tos <tos>
-    - set-var(<var-name>[,<cond>...]) <expr>
-    - set-var-fmt(<var-name>[,<cond>...]) <fmt>
-    - silent-drop [ rst-ttl <ttl> ]
-    - track-sc0 <key> [table <table>]
-    - track-sc1 <key> [table <table>]
-    - track-sc2 <key> [table <table>]
-    - unset-var(<var-name>)
-
-  The supported actions are described below.
+  The first keyword after "tcp-request session" in the syntax is the rule's
+  action, optionally followed by a varying number of arguments for the action.
+  The supported actions and their respective syntaxes are enumerated in
+  section 4.3 "Actions" (look for actions which tick "TCP RqSes").
 
   This directive is only available from named defaults sections, not anonymous
   ones. Rules defined in the defaults section are evaluated before ones in the
@@ -14036,112 +12093,6 @@ tcp-request session <action> [{if | unless} <condition>]
 
   See also : "tcp-request connection", "tcp-request content", "stick-table"
 
-tcp-request session accept [ { if | unless } <condition> ]
-
-  This is used to accept the connection. No further "tcp-request session"
-  rules are evaluated.
-
-tcp-request session attach-srv <srv> [name <expr>]
-
-  This is used to intercept the connection after proper HTTP/2 establishment.
-  The connection is reversed to the backend side and inserted into the idle
-  pool of <srv> server. This may only be used with servers having an 'rhttp@'
-  address.
-
-  An extra parameter <expr> can be specified. Its value is interpreted as a
-  sample expression to name the connection inside the server idle pool. When
-  routing an outgoing request through this server, this name will be matched
-  against the 'sni' parameter of the server line. Otherwise, the connection
-  will have no name and will only match requests without SNI.
-
-  This rule is only valid for frontend in HTTP mode. Also all listeners must
-  not require a protocol different from HTTP/2.
-
-tcp-request session reject [ { if | unless } <condition> ]
-
-  This is used to reject the connection. No further "tcp-request session" rules
-  are evaluated.
-
-tcp-request session sc-add-gpc(<idx>,<sc-id>) { <int> | <expr> }
-                                           [ { if | unless } <condition> ]
-
-  This action increments the General Purpose Counter according to the sticky
-  counter designated by <sc-id>. Please refer to "http-request sc-add-gpc" for
-  a complete description.
-
-tcp-request session sc-inc-gpc(<idx>,<sc-id>) [ { if | unless } <condition> ]
-tcp-request session sc-inc-gpc0(<sc-id>) [ { if | unless } <condition> ]
-tcp-request session sc-inc-gpc1(<sc-id>) [ { if | unless } <condition> ]
-
-  These actions increment the General Purppose Counters according to the sticky
-  counter designated by <sc-id>. Please refer to "http-request sc-inc-gpc",
-  "http-request sc-inc-gpc0" and "http-request sc-inc-gpc1" for a complete
-  description.
-
-tcp-request session sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
-                    [ { if | unless } <condition> ]
-tcp-request session sc-set-gpt0(<sc-id>) { <int> | <expr> }
-                    [ { if | unless } <condition> ]
-
-  These actions set the 32-bit unsigned General Purpose Tags according to the
-  sticky counter designated by <sc-id>. Please refer to "tcp-request connection
-  sc-set-gpt" and "tcp-request connection sc-set-gpt0" for a complete
-  description.
-
-tcp-request session set-dst <expr> [ { if | unless } <condition> ]
-tcp-request session set-dst-port <expr> [ { if | unless } <condition> ]
-
-  These actions are used to set the destination IP/Port address to the value of
-  specified expression. Please refer to "http-request set-dst" and
-  "http-request set-dst-port" for a complete description.
-
-tcp-request session set-mark <mark> [ { if | unless } <condition> ]
-
-  This action is used to set the Netfilter/IPFW MARK in all packets sent to the
-  client to the value passed in <mark> on platforms which support it. Please
-  refer to "http-request set-mark" for a complete description.
-
-tcp-request session set-src <expr> [ { if | unless } <condition> ]
-tcp-request session set-src-port <expr> [ { if | unless } <condition> ]
-
-  These actions are used to set the source IP/Port address to the value of
-  specified expression. Please refer to "http-request set-src" and
-  "http-request set-src-port" for a complete description.
-
-tcp-request session set-tos <tos> [ { if | unless } <condition> ]
-
-  This is used to set the TOS or DSCP field value of packets sent to the client
-  to the value passed in <tos> on platforms which support this. Please refer to
-  "http-request set-tos" for a complete description.
-
-tcp-request session set-var(<var-name>[,<cond>...]) <expr> [ { if | unless } <condition> ]
-tcp-request session set-var-fmt(<var-name>[,<cond>...]) <fmt> [ { if | unless } <condition> ]
-
-  This is used to set the contents of a variable. The variable is declared
-  inline. Please refer to "http-request set-var" and "http-request set-var-fmt"
-  for a complete description.
-
-tcp-request session silent-drop [ rst-ttl <ttl> ] [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and makes the client-facing connection
-  suddenly disappear using a system-dependent way that tries to prevent the
-  client from being notified. Please refer to "http-request silent-drop" for a
-  complete description.
-
-tcp-request session track-sc0 <key> [table <table>] [ { if | unless } <condition> ]
-tcp-request session track-sc1 <key> [table <table>] [ { if | unless } <condition> ]
-tcp-request session track-sc2  <key> [table <table>] [ { if | unless } <condition> ]
-
-  This enables tracking of sticky counters from current connection. Please
-  refer to "http-request track-sc0", "http-request track-sc1" and "http-request
-  track-sc2" for a complete description.
-
-tcp-request session unset-var(<var-name>) [ { if | unless } <condition> ]
-
-  This is used to unset a variable. Please refer to "http-request set-var" for
-  details about variables.
-
-
 tcp-response content <action> [{if | unless} <condition>]
   Perform an action on a session response depending on a layer 4-7 condition
   May be used in sections :   defaults | frontend | listen | backend
@@ -14154,9 +12105,9 @@ tcp-response content <action> [{if | unless} <condition>]
 
   Response contents can be analyzed at an early stage of response processing
   called "TCP content inspection". During this stage, ACL-based rules are
-  evaluated every time the response contents are updated, until either an
-  "accept", "close" or a "reject" rule matches, or a TCP response inspection
-  delay is set and expires with no matching rule.
+  evaluated every time the response contents are updated, until either a final
+  rule matches, or a TCP response inspection delay is set and expires with no
+  matching rule.
 
   Most often, these decisions will consider a protocol recognition or validity.
 
@@ -14165,29 +12116,10 @@ tcp-response content <action> [{if | unless} <condition>]
   contents. There is no specific limit to the number of rules which may be
   inserted.
 
-  The first keyword is the rule's action. Several types of actions are
-  supported:
-    - accept
-    - close
-    - reject
-    - sc-add-gpc(<idx>,<sc-id>) { <int> | <expr> }
-    - sc-inc-gpc(<idx>,<sc-id>)
-    - sc-inc-gpc0(<sc-id>)
-    - sc-inc-gpc1(<sc-id>)
-    - sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
-    - sc-set-gpt0(<sc-id>) { <int> | <expr> }
-    - send-spoe-group <engine-name> <group-name>
-    - set-bandwidth-limit <name> [limit {<expr> | <size>}] [period {<expr> | <time>}]
-    - set-log-level <level>
-    - set-mark <mark>
-    - set-nice <nice>
-    - set-tos <tos>
-    - set-var(<var-name>[,<cond>...]) <expr>
-    - set-var-fmt(<var-name>[,<cond>...]) <fmt>
-    - silent-drop [ rst-ttl <ttl> ]
-    - unset-var(<var-name>)
-
-  The supported actions are described below.
+  The first keyword after "tcp-response content" in the syntax is the rule's
+  action, optionally followed by a varying number of arguments for the action.
+  The supported actions and their respective syntaxes are enumerated in
+  section 4.3 "Actions" (look for actions which tick "TCP RsCnt").
 
   This directive is only available from named defaults sections, not anonymous
   ones. Rules defined in the defaults section are evaluated before ones in the
@@ -14212,106 +12144,6 @@ tcp-response content <action> [{if | unless} <condition>]
 
   See also : "tcp-request content", "tcp-response inspect-delay"
 
-tcp-response content accept [ { if | unless } <condition> ]
-
-  This is used to accept the response. No further "tcp-response content" rules
-  are evaluated.
-
-tcp-response content close [ { if | unless } <condition> ]
-
-  This is used to immediately closes the connection with the server. No further
-  "tcp-response content" rules are evaluated. The main purpose of this action
-  is to force a connection to be finished between a client and a server after
-  an exchange when the application protocol expects some long time outs to
-  elapse first. The goal is to eliminate idle connections which take
-  significant resources on servers with certain protocols.
-
-tcp-response content reject [ { if | unless } <condition> ]
-
-  This is used to reject the response. No further "tcp-response content" rules
-  are evaluated.
-
-tcp-response content sc-add-gpc(<idx>,<sc-id>) { <int> | <expr> }
-                                           [ { if | unless } <condition> ]
-
-  This action increments the General Purpose Counter according to the sticky
-  counter designated by <sc-id>. Please refer to "http-request sc-add-gpc" for
-  a complete description.
-
-tcp-response content sc-inc-gpc(<idx>,<sc-id>) [ { if | unless } <condition> ]
-tcp-response content sc-inc-gpc0(<sc-id>) [ { if | unless } <condition> ]
-tcp-response content sc-inc-gpc1(<sc-id>) [ { if | unless } <condition> ]
-
-  These actions increment the General Purppose Counters according to the sticky
-  counter designated by <sc-id>. Please refer to "http-request sc-inc-gpc",
-  "http-request sc-inc-gpc0" and "http-request sc-inc-gpc1" for a complete
-  description.
-
-tcp-response content sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
-                     [ { if | unless } <condition> ]
-tcp-resposne content sc-set-gpt0(<sc-id>) { <int> | <expr> }
-                     [ { if | unless } <condition> ]
-
-  These actions set the 32-bit unsigned General Purpose Tags according to the
-  sticky counter designated by <sc-id>. Please refer to "http-request
-  sc-set-gpt" and "http-request sc-set-gpt0" for a complete description.
-
-tcp-response content send-spoe-group <engine-name> <group-name>
-                     [ { if | unless } <condition> ]
-
-  This action is is used to trigger sending of a group of SPOE messages. Please
-  refer to "http-request send-spoe-group" for a complete description.
-
-
-tcp-response content set-bandwidth-limit <name> [limit { <expr> | <size> }]
-                 [period { <expr> | <time> }] [ { if | unless } <condition> ]
-
-  This action is used to enable the bandwidth limitation filter <name>, either
-  on the upload or download direction depending on the filter type. Please
-  refer to "http-request set-bandwidth-limit" for a complete description.
-
-tcp-response content set-log-level <level>  [ { if | unless } <condition> ]
-
-  This action is used to set the log level of the current session. Please refer
-  to "http-request set-log-level". for a complete description.
-
-tcp-response content set-mark <mark> [ { if | unless } <condition> ]
-
-  This action is used to set the Netfilter/IPFW MARK in all packets sent to the
-  client to the value passed in <mark> on platforms which support it. Please
-  refer to "http-request set-mark" for a complete description.
-
-tcp-response content set-nice <nice> [ { if | unless } <condition> ]
-
-  This sets the "nice" factor of the current request being processed. Please
-  refer to "http-request set-nice" for a complete description.
-
-tcp-response content set-tos <tos> [ { if | unless } <condition> ]
-
-  This is used to set the TOS or DSCP field value of packets sent to the client
-  to the value passed in <tos> on platforms which support this. Please refer to
-  "http-request set-tos" for a complete description.
-
-tcp-response content set-var(<var-name>[,<cond>...]) <expr> [ { if | unless } <condition> ]
-tcp-response content set-var-fmt(<var-name>[,<cond>...]) <fmt> [ { if | unless } <condition> ]
-
-  This is used to set the contents of a variable. The variable is declared
-  inline. Please refer to "http-request set-var" and "http-request set-var-fmt"
-  for a complete description.
-
-tcp-response content silent-drop [ rst-ttl <ttl> ] [ { if | unless } <condition> ]
-
-  This stops the evaluation of the rules and makes the client-facing connection
-  suddenly disappear using a system-dependent way that tries to prevent the
-  client from being notified. Please refer to "http-request silent-drop" for a
-  complete description.
-
-tcp-response content unset-var(<var-name>) [ { if | unless } <condition> ]
-
-  This is used to unset a variable. Please refer to "http-request set-var" for
-  details about variables.
-
-
 tcp-response inspect-delay <timeout>
   Set the maximum allowed time to wait for a response during content inspection
   May be used in sections :   defaults | frontend | listen | backend
@@ -14912,6 +12744,1537 @@ use-server <server> unless <condition>
   See also: "use_backend", section 5 about server and section 7 about ACLs.
 
 
+4.3. Actions keywords matrix
+----------------------------
+
+Several rule sets are evaluated at various stages of the request or response
+processing, and for each rule found in these rule sets, an action may be
+executed if the optional condition is met.
+
+A large number of actions are provided by default, they can modify contents,
+accept/block processing, change internal states etc. And it is possible to
+define new actions in Lua (in which case their names will always be prefixed
+with "lua.").
+
+While historically some actions did only exist in specific rule sets, nowadays
+many actions are usable with many rule sets. The listing in this section will
+indicate for which supported action where it may be used, by ticking the
+corresponding abbreviated entry names among the following rule sets:
+
+  - TCP RqCon: the action is valid for "tcp-request connection" rules
+  - TCP RqSes: the action is valid for "tcp-request session" rules
+  - TCP RqCnt: the action is valid for "tcp-request content" rules
+  - TCP RsCnt: the action is valid for "tcp-response content" rules
+  - HTTP  Req:  the action is valid for "http-request" rules
+  - HTTP  Res:  the action is valid for "http-response" rules
+  - HTTP  Aft:  the action is valid for "http-after-response" rules
+
+The same abbreviations are used in the reference section 4.4 below.
+
+
+ keyword                TCP: RqCon RqSes RqCnt RsCnt   HTTP: Req Res Aft
+----------------------+-----------+-----+-----+------+----------+---+----
+accept                         X     X     X     X            -   -   -
+add-acl                        -     -     -     -            X   X   -
+add-header                     -     -     -     -            X   X   X
+allow                          -     -     -     -            X   X   X
+attach-srv                     -     X     -     -            -   -   -
+auth                           -     -     -     -            X   -   -
+cache-store                    -     -     -     -            -   X   -
+cache-use                      -     -     -     -            X   -   -
+capture                        -     -     X     -            X   X   X
+close                          -     -     -     X            -   -   -
+del-acl                        -     -     -     -            X   X   -
+del-header                     -     -     -     -            X   X   X
+del-map                        -     -     -     -            X   X   X
+deny                           -     -     -     -            X   X   -
+disable-l7-retry               -     -     -     -            X   -   -
+do-resolve                     -     -     X     -            X   -   -
+early-hint                     -     -     -     -            X   -   -
+expect-netscaler-cip           X     -     -     -            -   -   -
+expect-proxy layer4            X     -     -     -            -   -   -
+normalize-uri                  -     -     -     -            X   -   -
+redirect                       -     -     -     -            X   X   -
+reject                         X     X     X     X            X   -   -
+replace-header                 -     -     -     -            X   X   X
+replace-path                   -     -     -     -            X   -   -
+replace-pathq                  -     -     -     -            X   -   -
+replace-uri                    -     -     -     -            X   -   -
+replace-value                  -     -     -     -            X   X   X
+return                         -     -     -     -            X   X   -
+sc-add-gpc                     X     X     X     X            X   X   X
+--keyword---------------TCP--RqCon-RqSes-RqCnt-RsCnt---HTTP--Req-Res-Aft-
+sc-inc-gpc                     X     X     X     X            X   X   X
+sc-inc-gpc0                    X     X     X     X            X   X   X
+sc-inc-gpc1                    X     X     X     X            X   X   X
+sc-set-gpt                     X     X     X     X            X   X   X
+sc-set-gpt0                    X     X     X     X            X   X   X
+send-spoe-group                -     -     X     X            X   X   -
+set-bandwidth-limit            -     -     X     X            X   X   -
+set-dst <expr>                 X     X     X     -            X   -   -
+set-dst-port                   X     X     X     -            X   -   -
+set-header                     -     -     -     -            X   X   X
+set-log-level                  -     -     X     X            X   X   X
+set-map                        -     -     -     -            X   X   X
+set-mark                       X     X     X     X            X   X   -
+set-method                     -     -     -     -            X   -   -
+set-nice                       -     -     X     X            X   X   -
+set-path                       -     -     -     -            X   -   -
+set-pathq                      -     -     -     -            X   -   -
+set-priority-class             -     -     X     -            X   -   -
+set-priority-offset            -     -     X     -            X   -   -
+--keyword---------------TCP--RqCon-RqSes-RqCnt-RsCnt---HTTP--Req-Res-Aft-
+set-query                      -     -     -     -            X   -   -
+set-src                        X     X     X     -            X   -   -
+set-src-port                   X     X     X     -            X   -   -
+set-status                     -     -     -     -            -   X   X
+set-timeout                    -     -     -     -            X   X   -
+set-tos                        X     X     X     X            X   X   -
+set-uri                        -     -     -     -            X   -   -
+set-var                        X     X     X     X            X   X   X
+set-var-fmt                    X     X     X     X            X   X   X
+silent-drop                    X     X     X     X            X   X   -
+strict-mode                    -     -     -     -            X   X   X
+switch-mode                    -     -     X     -            -   -   -
+tarpit                         -     -     -     -            X   -   -
+track-sc1                      X     X     X     -            X   X   -
+track-sc2                      X     X     X     -            X   X   -
+unset-var                      X     X     X     X            X   X   X
+use-service                    -     -     X     -            X   -   -
+wait-for-body                  -     -     -     -            X   X   -
+wait-for-handshake             -     -     -     -            X   -   -
+--keyword---------------TCP--RqCon-RqSes-RqCnt-RsCnt---HTTP--Req-Res-Aft-
+
+
+4.4. Alphabetically sorted actions reference
+--------------------------------------------
+
+This section provides a detailed description of each action and its usage,
+using the same ruleset terminology marking as described in section 4.3 above.
+
+
+accept
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt |   HTTP Req| Res| Aft
+                    X  |   X  |   X  |   X   |         - |  - |  -
+
+  This stops the evaluation of the rules and lets the request or response pass
+  the check. This action is final, i.e. no further rules from the same rule set
+  are evaluated for the current section. There is no difference between this
+  and the "allow" action except that for historical compatibility, "accept" is
+  used for TCP rules and "allow" for HTTP rules. See also the "allow" action
+  below.
+
+
+add-acl(<file-name>) <key fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  -
+
+  This is used to add a new entry into an ACL. The ACL must be loaded from a
+  file (even a dummy empty file). The file name of the ACL to be updated is
+  passed between parentheses. It takes one argument: <key fmt>, which follows
+  log-format rules, to collect content of the new entry. It performs a lookup
+  in the ACL before insertion, to avoid duplicated (or more) values.
+  It is the equivalent of the "add acl" command from the stats socket, but can
+  be triggered by an HTTP request.
+
+
+add-header <name> <fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  X
+
+  This appends an HTTP header field whose name is specified in <name> and
+  whose value is defined by <fmt> which follows the log-format rules (see
+  Custom Log Format in section 8.2.4). This is particularly useful to pass
+  connection-specific information to the server (e.g. the client's SSL
+  certificate), or to combine several headers into one. This rule is not
+  final, so it is possible to add other similar rules. Note that header
+  addition is performed immediately, so one rule might reuse the resulting
+  header from a previous rule.
+
+
+allow
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  X
+
+  This stops the evaluation of the rules and lets the request pass the check.
+  This action is final, i.e. no further rules from the same rule set are
+  evaluated for the current section. There is no difference between this and
+  the "accept" action except that for historical compatibility, "accept" is
+  used for TCP rules and "allow" for HTTP rules. See also the "accept" action
+  above.
+
+
+attach-srv <srv> [name <expr>]
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   X  |   -  |   -  |          - |  - |  -
+
+  This is used to intercept the connection after proper HTTP/2 establishment.
+  The connection is reversed to the backend side and inserted into the idle
+  pool of server <srv>. This may only be used with servers having an 'rhttp@'
+  address.
+
+  An extra parameter <expr> can be specified. Its value is interpreted as a
+  sample expression to name the connection inside the server idle pool. When
+  routing an outgoing request through this server, this name will be matched
+  against the 'sni' parameter of the server line. Otherwise, the connection
+  will have no name and will only match requests without SNI.
+
+  This rule is only valid for frontend in HTTP mode. Also all listeners must
+  not require a protocol different from HTTP/2.
+
+
+auth [realm <realm>]
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  - |  -
+
+  This stops the evaluation of the rules and immediately responds with an
+  HTTP 401 or 407 error code to invite the user to present a valid user name
+  and password. No further "http-request" rules are evaluated. An optional
+  "realm" parameter is supported, it sets the authentication realm that is
+  returned with the response (typically the application's name).
+
+  The corresponding proxy's error message is used. It may be customized using
+  an "errorfile" or an "http-error" directive. For 401 responses, all
+  occurrences of the WWW-Authenticate header are removed and replaced by a new
+  one with a basic authentication challenge for realm "<realm>". For 407
+  responses, the same is done on the Proxy-Authenticate header. If the error
+  message must not be altered, consider to use "http-request return" rule
+  instead.
+
+  Example:
+        acl auth_ok http_auth_group(L1) G1
+        http-request auth unless auth_ok
+
+
+cache-store <name>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          - |  X |  -
+
+  See section 6.2 about cache setup.
+
+
+cache-use <name>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  - |  -
+
+  See section 6.2 about cache setup.
+
+
+capture <sample> [ len <length> | id <id> ]
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   X  |   -  |          X |  X |  X
+
+  This captures sample expression <sample> from the request or response buffer,
+  and converts it to a string of at most <len> characters. The resulting string
+  is stored into the next "capture" slot (either request or reponse), so it
+  will possibly appear next to some captured HTTP headers. It will then
+  automatically appear in the logs, and it will be possible to extract it using
+  sample fetch methods to feed it into headers or anything. The length should
+  be limited given that this size will be allocated for each capture during the
+  whole session life. Note that the length is only usable with "http-request"
+  rules. Please check section 7.3 (Fetching samples), "capture request header"
+  and "capture response header" for more information.
+
+  If the keyword "id" is used instead of "len", the action tries to store the
+  captured string in a previously declared capture slot. This is useful to run
+  captures in backends. The slot id can be declared by a previous directive
+  "http-request capture" or with the "declare capture" keyword.
+
+  When using this action in a backend, please double check that the relevant
+  frontend(s) have the required capture slots otherwise, this rule will be
+  ignored at run time. This can't be detected at configuration parsing time due
+  to HAProxy's ability to dynamically resolve backend name at runtime.
+
+
+close
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   X  |          - |  - |  -
+
+  This is used to immediately close the connection with the server. No further
+  "tcp-response content" rules are evaluated. The main purpose of this action
+  is to force a connection to be finished between a client and a server after
+  an exchange when the application protocol expects some long time outs to
+  elapse first. The goal is to eliminate idle connections which take
+  significant resources on servers with certain protocols.
+
+
+del-acl(<file-name>) <key fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  -
+
+  This is used to delete an entry from an ACL. The ACL must be loaded from a
+  file (even a dummy empty file). The file name of the ACL to be updated is
+  passed between parentheses. It takes one argument: <key fmt>, which follows
+  log-format rules, to collect content of the entry to delete.
+  It is the equivalent of the "del acl" command from the stats socket, but can
+  be triggered by an HTTP request or response.
+
+
+del-header <name> [ -m <meth> ]
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  X
+
+  This removes all HTTP header fields whose name is specified in <name>. <meth>
+  is the matching method, applied on the header name. Supported matching methods
+  are "str" (exact match), "beg" (prefix match), "end" (suffix match), "sub"
+  (substring match) and "reg" (regex match). If not specified, exact matching
+  method is used.
+
+
+del-map(<file-name>) <key fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  X
+
+  This is used to delete an entry from a MAP. The MAP must be loaded from a
+  file (even a dummy empty file). The file name of the MAP to be updated is
+  passed between parentheses. It takes one argument: <key fmt>, which follows
+  log-format rules, to collect content of the entry to delete.
+  It takes one argument: "file name" It is the equivalent of the "del map"
+  command from the stats socket, but can be triggered by an HTTP request or
+  response.
+
+
+deny [ { status | deny_status } <code> ] [ content-type <type> ]
+     [ { default-errorfiles | errorfile <file> | errorfiles <name> |
+       file <file> | lf-file <file> | string <str> | lf-string <fmt> } ]
+     [ hdr <name> <fmt> ]*
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  -
+
+  This stops the evaluation of the rules and immediately rejects the request or
+  response. By default an HTTP 403 error is returned for requests, and 502 for
+  responses, but the returned response may be customized using same syntax as
+  for the "return" action. Thus, see "return" below for details. For
+  compatibility purposes, when no argument is defined, or only "deny_status",
+  the argument "default-errorfiles" is implied. It means "deny [deny_status
+  <status>]" is an alias of "deny [status <status>] default-errorfiles". This
+  action is final, i.e. no further rules from the same rule set are evaluated
+  for the current section. See also the "return" action for the advanced
+  syntax.
+
+
+disable-l7-retry
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  - |  -
+
+  This disables any attempt to retry the request if it fails for any other
+  reason than a connection failure. This can be useful for example to make
+  sure POST requests aren't retried on failure.
+
+
+do-resolve(<var>,<resolvers>,[ipv4,ipv6]) <expr>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   X  |   -  |          X |  - |  -
+
+  This action performs a DNS resolution of the output of <expr> and stores
+  the result in the variable <var>. It uses the DNS resolvers section
+  pointed by <resolvers>.
+  It is possible to choose a resolution preference using the optional
+  arguments 'ipv4' or 'ipv6'.
+  When performing the DNS resolution, the client side connection is on
+  pause waiting till the end of the resolution.
+  If an IP address can be found, it is stored into <var>. If any kind of
+  error occurs, then <var> is not set.
+  One can use this action to discover a server IP address at run time and
+  based on information found in the request (IE a Host header).
+  If this action is used to find the server's IP address (using the
+  "set-dst" action), then the server IP address in the backend must be set
+  to 0.0.0.0. The do-resolve action takes an host-only parameter, any port must
+  be removed from the string.
+
+  Example:
+    resolvers mydns
+      nameserver local 127.0.0.53:53
+      nameserver google 8.8.8.8:53
+      timeout retry   1s
+      hold valid 10s
+      hold nx 3s
+      hold other 3s
+      hold obsolete 0s
+      accepted_payload_size 8192
+
+    frontend fe
+      bind 10.42.0.1:80
+      http-request do-resolve(txn.myip,mydns,ipv4) hdr(Host),host_only
+      http-request capture var(txn.myip) len 40
+
+      # return 503 when the variable is not set,
+      # which mean DNS resolution error
+      use_backend b_503 unless { var(txn.myip) -m found }
+
+      default_backend be
+
+    backend b_503
+      # dummy backend used to return 503.
+      # one can use the errorfile directive to send a nice
+      # 503 error page to end users
+
+    backend be
+      # rule to prevent HAProxy from reconnecting to services
+      # on the local network (forged DNS name used to scan the network)
+      http-request deny if { var(txn.myip) -m ip 127.0.0.0/8 10.0.0.0/8 }
+      http-request set-dst var(txn.myip)
+      server clear 0.0.0.0:0
+
+  NOTE: Don't forget to set the "protection" rules to ensure HAProxy won't
+        be used to scan the network or worst won't loop over itself...
+
+
+early-hint <name> <fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  - |  -
+
+  This is used to build an HTTP 103 Early Hints response prior to any other one.
+  This appends an HTTP header field to this response whose name is specified in
+  <name> and whose value is defined by <fmt> which follows the log-format rules
+  (see Custom Log Format in section 8.2.4). This is particularly useful to pass
+  to the client some Link headers to preload resources required to render the
+  HTML documents.
+
+  See RFC 8297 for more information.
+
+
+expect-netscaler-cip layer4
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   -  |   -  |   -  |          - |  - |  -
+
+  This configures the client-facing connection to receive a NetScaler Client IP
+  insertion protocol header before any byte is read from the socket.  This is
+  equivalent to having the "accept-netscaler-cip" keyword on the "bind" line,
+  except that using the TCP rule allows the PROXY protocol to be accepted only
+  for certain IP address ranges using an ACL. This is convenient when multiple
+  layers of load balancers are passed through by traffic coming from public
+  hosts.
+
+
+expect-proxy layer4
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   -  |   -  |   -  |          - |  - |  -
+
+  This configures the client-facing connection to receive a PROXY protocol
+  header before any byte is read from the socket. This is equivalent to having
+  the "accept-proxy" keyword on the "bind" line, except that using the TCP rule
+  allows the PROXY protocol to be accepted only for certain IP address ranges
+  using an ACL. This is convenient when multiple layers of load balancers are
+  passed through by traffic coming from public hosts.
+
+
+normalize-uri <normalizer>
+normalize-uri fragment-encode
+normalize-uri fragment-strip
+normalize-uri path-merge-slashes
+normalize-uri path-strip-dot
+normalize-uri path-strip-dotdot [ full ]
+normalize-uri percent-decode-unreserved [ strict ]
+normalize-uri percent-to-uppercase [ strict ]
+normalize-uri query-sort-by-name
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  - |  -
+
+  Performs normalization of the request's URI.
+
+  URI normalization in HAProxy 2.4 is currently available as an experimental
+  technical preview. As such, it requires the global directive
+  'expose-experimental-directives' first to be able to invoke it. You should be
+  prepared that the behavior of normalizers might change to fix possible
+  issues, possibly breaking proper request processing in your infrastructure.
+
+  Each normalizer handles a single type of normalization to allow for a
+  fine-grained selection of the level of normalization that is appropriate for
+  the supported backend.
+
+  As an example the "path-strip-dotdot" normalizer might be useful for a static
+  fileserver that directly maps the requested URI to the path within the local
+  filesystem. However it might break routing of an API that expects a specific
+  number of segments in the path.
+
+  It is important to note that some normalizers might result in unsafe
+  transformations for broken URIs. It might also be possible that a combination
+  of normalizers that are safe by themselves results in unsafe transformations
+  when improperly combined.
+
+  As an example the "percent-decode-unreserved" normalizer might result in
+  unexpected results when a broken URI includes bare percent characters. One
+  such a broken URI is "/%%36%36" which would be decoded to "/%66" which in
+  turn is equivalent to "/f". By specifying the "strict" option requests to
+  such a broken URI would safely be rejected.
+
+  The following normalizers are available:
+
+  - fragment-encode: Encodes "#" as "%23".
+
+      The "fragment-strip" normalizer should be preferred, unless it is known
+      that broken clients do not correctly encode '#' within the path component.
+
+      Example:
+      - /#foo  -> /%23foo
+
+  - fragment-strip: Removes the URI's "fragment" component.
+
+      According to RFC 3986#3.5 the "fragment" component of an URI should not
+      be sent, but handled by the User Agent after retrieving a resource.
+
+      This normalizer should be applied first to ensure that the fragment is
+      not interpreted as part of the request's path component.
+
+      Example:
+      - /#foo  -> /
+
+  - path-strip-dot: Removes "/./" segments within the "path" component
+      (RFC 3986#6.2.2.3).
+
+      Segments including percent encoded dots ("%2E") will not be detected. Use
+      the "percent-decode-unreserved" normalizer first if this is undesired.
+
+      Example:
+      - /.            -> /
+      - /./bar/       -> /bar/
+      - /a/./a        -> /a/a
+      - /.well-known/ -> /.well-known/ (no change)
+
+  - path-strip-dotdot: Normalizes "/../" segments within the "path" component
+      (RFC 3986#6.2.2.3).
+
+      This merges segments that attempt to access the parent directory with
+      their preceding segment.
+
+      Empty segments do not receive special treatment. Use the "merge-slashes"
+      normalizer first if this is undesired.
+
+      Segments including percent encoded dots ("%2E") will not be detected. Use
+      the "percent-decode-unreserved" normalizer first if this is undesired.
+
+      Example:
+      - /foo/../     -> /
+      - /foo/../bar/ -> /bar/
+      - /foo/bar/../ -> /foo/
+      - /../bar/     -> /../bar/
+      - /bar/../../  -> /../
+      - /foo//../    -> /foo/
+      - /foo/%2E%2E/ -> /foo/%2E%2E/
+
+      If the "full" option is specified then "../" at the beginning will be
+      removed as well:
+
+      Example:
+      - /../bar/     -> /bar/
+      - /bar/../../  -> /
+
+  - path-merge-slashes: Merges adjacent slashes within the "path" component
+      into a single slash.
+
+      Example:
+      - //        -> /
+      - /foo//bar -> /foo/bar
+
+  - percent-decode-unreserved: Decodes unreserved percent encoded characters to
+      their representation as a regular character (RFC 3986#6.2.2.2).
+
+      The set of unreserved characters includes all letters, all digits, "-",
+      ".", "_", and "~".
+
+      Example:
+      - /%61dmin       -> /admin
+      - /foo%3Fbar=baz -> /foo%3Fbar=baz (no change)
+      - /%%36%36       -> /%66           (unsafe)
+      - /%ZZ           -> /%ZZ
+
+      If the "strict" option is specified then invalid sequences will result
+      in a HTTP 400 Bad Request being returned.
+
+      Example:
+      - /%%36%36 -> HTTP 400
+      - /%ZZ     -> HTTP 400
+
+  - percent-to-uppercase: Uppercases letters within percent-encoded sequences
+      (RFC 3986#6.2.2.1).
+
+      Example:
+      - /%6f -> /%6F
+      - /%zz -> /%zz
+
+      If the "strict" option is specified then invalid sequences will result
+      in a HTTP 400 Bad Request being returned.
+
+      Example:
+      - /%zz -> HTTP 400
+
+  - query-sort-by-name: Sorts the query string parameters by parameter name.
+      Parameters are assumed to be delimited by '&'. Shorter names sort before
+      longer names and identical parameter names maintain their relative order.
+
+      Example:
+      - /?c=3&a=1&b=2         -> /?a=1&b=2&c=3
+      - /?aaa=3&a=1&aa=2      -> /?a=1&aa=2&aaa=3
+      - /?a=3&b=4&a=1&b=5&a=2 -> /?a=3&a=1&a=2&b=4&b=5
+
+
+redirect <rule>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  -
+
+  This performs an HTTP redirection based on a redirect rule. This is exactly
+  the same as the "redirect" statement except that it inserts a redirect rule
+  which is processed in the middle of other "http-request" or "http-response"
+  rules and that these rules use the "log-format" strings. For responses, only
+  the "location" type of redirect is permitted. In addition, when a redirect is
+  performed during a response, the transfer from the server to HAProxy is
+  interrupted so that no payload can be forwarded to the client. This may cause
+  some connections to be closed on HTTP/1. This action is final, i.e. no
+  further rules from the same rule set are evaluated for the current section.
+  See the "redirect" keyword for the rule's syntax.
+
+
+reject
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   X  |          X |  - |  -
+
+  This stops the evaluation of the rules and immediately closes the connection
+  without sending any response. For HTTP rules, it acts similarly to the
+  "tcp-request content reject" rules. It can be useful to force an immediate
+  connection closure on HTTP/2 connections.
+
+  In "tcp-request connection" rules, rejected connections do not even become a
+  session, which is why they are accounted separately for in the stats, as
+  "denied connections". They are not considered for the session rate-limit and
+  are not logged either. The reason is that these rules should only be used to
+  filter extremely high connection rates such as the ones encountered during a
+  massive DDoS attack. Under these extreme conditions, the simple action of
+  logging each event would make the system collapse and would considerably
+  lower the filtering capacity. If logging is absolutely desired, then
+  "tcp-request content" rules should be used instead, as "tcp-request session"
+  rules will not log either.
+
+  When used in "tcp-response content" rules, the server connection will be
+  closed and the response aborted. This is generally used to prevent sensitive
+  information from leaking, typically after inspecting contents in conjunction
+  with the "wait-for-body" action.
+
+
+replace-header <name> <match-regex> <replace-fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  X
+
+  This matches the value of all occurrences of header field <name> against
+  <match-regex>. Matching is performed case-sensitively. Matching values are
+  completely replaced by <replace-fmt>. Format characters are allowed in
+  <replace-fmt> and work like <fmt> arguments in "http-request add-header".
+  Standard back-references using the backslash ('\') followed by a number are
+  supported.
+
+  This action acts on whole header lines, regardless of the number of values
+  they may contain. Thus it is well-suited to process headers naturally
+  containing commas in their value, such as If-Modified-Since or Set-Cookie.
+  Headers that contain a comma-separated list of values, such as Accept, or
+  Cache-Control should be processed using the "replace-value" action instead.
+  See also the "replace-value" action.
+
+  Example:
+    http-request replace-header Cookie foo=([^;]*);(.*) foo=\1;ip=%bi;\2
+
+    # applied to:
+    Cookie: foo=foobar; expires=Tue, 14-Jun-2016 01:40:45 GMT;
+
+    # outputs:
+    Cookie: foo=foobar;ip=192.168.1.20; expires=Tue, 14-Jun-2016 01:40:45 GMT;
+
+    # assuming the backend IP is 192.168.1.20
+
+    http-request replace-header User-Agent curl foo
+
+    # applied to:
+    User-Agent: curl/7.47.0
+
+    # outputs:
+    User-Agent: foo
+
+  Example:
+    http-response replace-header Set-Cookie (C=[^;]*);(.*) \1;ip=%bi;\2
+
+    # applied to:
+    Set-Cookie: C=1; expires=Tue, 14-Jun-2016 01:40:45 GMT
+
+    # outputs:
+    Set-Cookie: C=1;ip=192.168.1.20; expires=Tue, 14-Jun-2016 01:40:45 GMT
+
+    # assuming the backend IP is 192.168.1.20.
+
+
+replace-path <match-regex> <replace-fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  - |  -
+
+  This works like "replace-header" except that it works on the request's path
+  component instead of a header. The path component starts at the first '/'
+  after an optional scheme+authority and ends before the question mark. Thus,
+  the replacement does not modify the scheme, the authority and the
+  query-string.
+
+  It is worth noting that regular expressions may be more expensive to evaluate
+  than certain ACLs, so rare replacements may benefit from a condition to avoid
+  performing the evaluation at all if it does not match.
+
+  Example:
+    # prefix /foo : turn /bar?q=1 into /foo/bar?q=1 :
+    http-request replace-path (.*) /foo\1
+
+    # strip /foo : turn /foo/bar?q=1 into /bar?q=1
+    http-request replace-path /foo/(.*) /\1
+    # or more efficient if only some requests match :
+    http-request replace-path /foo/(.*) /\1 if { url_beg /foo/ }
+
+
+replace-pathq <match-regex> <replace-fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  - |  -
+
+  This does the same as "http-request replace-path" except that the path
+  contains the query-string if any is present. Thus, the path and the
+  query-string are replaced.
+
+  Example:
+    # suffix /foo : turn /bar?q=1 into /bar/foo?q=1 :
+    http-request replace-pathq ([^?]*)(\?(.*))? \1/foo\2
+
+
+replace-uri <match-regex> <replace-fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  - |  -
+
+  This works like "replace-header" except that it works on the request's URI part
+  instead of a header. The URI part may contain an optional scheme, authority or
+  query string. These are considered to be part of the value that is matched
+  against.
+
+  It is worth noting that regular expressions may be more expensive to evaluate
+  than certain ACLs, so rare replacements may benefit from a condition to avoid
+  performing the evaluation at all if it does not match.
+
+  IMPORTANT NOTE: historically in HTTP/1.x, the vast majority of requests sent
+  by browsers use the "origin form", which differs from the "absolute form" in
+  that they do not contain a scheme nor authority in the URI portion. Mostly
+  only requests sent to proxies, those forged by hand and some emitted by
+  certain applications use the absolute form. As such, "replace-uri" usually
+  works fine most of the time in HTTP/1.x with rules starting with a "/". But
+  with HTTP/2, clients are encouraged to send absolute URIs only, which look
+  like the ones HTTP/1 clients use to talk to proxies. Such partial replace-uri
+  rules may then fail in HTTP/2 when they work in HTTP/1. Either the rules need
+  to be adapted to optionally match a scheme and authority, or replace-path
+  should be used.
+
+  Example:
+    # rewrite all "http" absolute requests to "https":
+    http-request replace-uri ^http://(.*) https://\1
+
+    # prefix /foo : turn /bar?q=1 into /foo/bar?q=1 :
+    http-request replace-uri ([^/:]*://[^/]*)?(.*) \1/foo\2
+
+
+replace-value <name> <match-regex> <replace-fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  X
+
+  This works like "replace-header" except that it matches the regex against
+  every comma-delimited value of the header field <name> instead of the
+  entire header. This is suited for all headers which are allowed to carry
+  more than one value. An example could be the Accept request header, or
+  Cache-Control for requests or responses.
+
+  Example:
+    http-request replace-value X-Forwarded-For ^192\.168\.(.*)$ 172.16.\1
+
+    # applied to:
+    X-Forwarded-For: 192.168.10.1, 192.168.13.24, 10.0.0.37
+
+    # outputs:
+    X-Forwarded-For: 172.16.10.1, 172.16.13.24, 10.0.0.37
+
+  Example:
+    http-after-response replace-value Cache-control ^public$ private
+
+    # applied to:
+    Cache-Control: max-age=3600, public
+
+    # outputs:
+    Cache-Control: max-age=3600, private
+
+
+return [ status <code> ] [ content-type <type> ]
+       [ { default-errorfiles | errorfile <file> | errorfiles <name> |
+         file <file> | lf-file <file> | string <str> | lf-string <fmt> } ]
+       [ hdr <name> <fmt> ]*
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  -
+
+  This stops the evaluation of the rules and immediately returns a response. The
+  default status code used for the response is 200. It can be optionally
+  specified as an arguments to "status". The response content-type may also be
+  specified as an argument to "content-type". Finally the response itself may
+  be defined. It can be a full HTTP response specifying the errorfile to use,
+  or the response payload specifying the file or the string to use. These rules
+  are followed to create the response :
+
+  * If neither the errorfile nor the payload to use is defined, a dummy
+    response is returned. Only the "status" argument is considered. It can be
+    any code in the range [200, 599]. The "content-type" argument, if any, is
+    ignored.
+
+  * If "default-errorfiles" argument is set, the proxy's errorfiles are
+    considered.  If the "status" argument is defined, it must be one of the
+    status code handled by HAProxy (200, 400, 403, 404, 405, 408, 410, 413,
+    425, 429, 500, 501, 502, 503, and 504). The "content-type" argument, if
+    any, is ignored.
+
+  * If a specific errorfile is defined, with an "errorfile" argument, the
+    corresponding file, containing a full HTTP response, is returned. Only the
+    "status" argument is considered. It must be one of the status code handled
+    by HAProxy (200, 400, 403, 404, 405, 408, 410, 413, 425, 429, 500, 501,
+    502, 503, and 504). The "content-type" argument, if any, is ignored.
+
+  * If an http-errors section is defined, with an "errorfiles" argument, the
+    corresponding file in the specified http-errors section, containing a full
+    HTTP response, is returned. Only the "status" argument is considered. It
+    must be one of the status code handled by HAProxy (200, 400, 403, 404, 405,
+    408, 410, 413, 425, 429, 500, 501, 502, 503, and 504). The "content-type"
+    argument, if any, is ignored.
+
+  * If a "file" or a "lf-file" argument is specified, the file's content is
+    used as the response payload. If the file is not empty, its content-type
+    must be set as argument to "content-type". Otherwise, any "content-type"
+    argument is ignored. With a "lf-file" argument, the file's content is
+    evaluated as a log-format string. With a "file" argument, it is considered
+    as a raw content.
+
+  * If a "string" or "lf-string" argument is specified, the defined string is
+    used as the response payload. The content-type must always be set as
+    argument to "content-type". With a "lf-string" argument, the string is
+    evaluated as a log-format string. With a "string" argument, it is
+    considered as a raw string.
+
+  When the response is not based on an errorfile, it is possible to append HTTP
+  header fields to the response using "hdr" arguments. Otherwise, all "hdr"
+  arguments are ignored. For each one, the header name is specified in <name>
+  and its value is defined by <fmt> which follows the log-format rules.
+
+  Note that the generated response must be smaller than a buffer. And to avoid
+  any warning, when an errorfile or a raw file is loaded, the buffer space
+  reserved for the headers rewriting should also be free.
+
+  This action is final, i.e. no further rules from the same rule set are
+  evaluated for the current section.
+
+  Example:
+    http-request return errorfile /etc/haproxy/errorfiles/200.http \
+        if { path /ping }
+
+    http-request return content-type image/x-icon file /var/www/favicon.ico  \
+        if { path /favicon.ico }
+
+    http-request return status 403 content-type text/plain    \
+        lf-string "Access denied. IP %[src] is blacklisted."  \
+        if { src -f /etc/haproxy/blacklist.lst }
+
+
+sc-add-gpc(<idx>,<sc-id>) { <int> | <expr> }
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   X  |          X |  X |  X
+
+  This action increments the General Purpose Counter at the index <idx> of the
+  array associated to the sticky counter designated by <sc-id> by the value of
+  either integer <int> or the integer evaluation of expression <expr>. Integers
+  and expressions are limited to unsigned 32-bit values. If an error occurs,
+  this action silently fails and the actions evaluation continues. <idx> is an
+  integer between 0 and 99 and <sc-id> is an integer between 0 and 2. It also
+  silently fails if the there is no GPC stored at this index. The entry in the
+  table is refreshed even if the value is zero. The 'gpc_rate' is automatically
+  adjusted to reflect the average growth rate of the gpc value.
+
+  This action applies only to the 'gpc' and 'gpc_rate' array data_types (and
+  not to the legacy 'gpc0', 'gpc1', 'gpc0_rate' nor 'gpc1_rate' data_types).
+  There is no equivalent function for legacy data types, but if the value is
+  always 1, please see 'sc-inc-gpc()', 'sc-inc-gpc0()' and 'sc-inc-gpc1()'.
+  There is no way to decrement the value either, but it is possible to store
+  exact values in a General Purpose Tag using 'sc-set-gpt()' instead.
+
+  The main use of this action is to count scores or total volumes (e.g.
+  estimated danger per source IP reported by the server or a WAF, total
+  uploaded bytes, etc).
+
+
+sc-inc-gpc(<idx>,<sc-id>)
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   X  |          X |  X |  X
+
+  This actions increments the General Purpose Counter at the index <idx> of the
+  array associated to the sticky counter designated by <sc-id>. If an error
+  occurs, this action silently fails and the actions evaluation continues.
+  <idx> is an integer between 0 and 99 and <sc-id> is an integer between 0 and
+  2. It also silently fails if the there is no GPC stored at this index. This
+  action applies only to the 'gpc' and 'gpc_rate' array data_types (and not to
+  the legacy 'gpc0', 'gpc1', 'gpc0_rate' nor 'gpc1_rate' data_types).
+
+
+sc-inc-gpc0(<sc-id>)
+sc-inc-gpc1(<sc-id>)
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   X  |          X |  X |  X
+
+  This actions increments the GPC0 or GPC1 counter according with the sticky
+  counter designated by <sc-id>. If an error occurs, this action silently fails
+  and the actions evaluation continues.
+
+
+sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   X  |          X |  X |  X
+
+  This action sets the 32-bit unsigned GPT at the index <idx> of the array
+  associated to the sticky counter designated by <sc-id> at the value of
+  <int>/<expr>. The expected result is a boolean.
+
+  If an error occurs, this action silently fails and the actions evaluation
+  continues. <idx> is an integer between 0 and 99 and <sc-id> is an integer
+  between 0 and 2. It also silently fails if the there is no GPT stored
+  at this index.
+
+  This action applies only to the 'gpt' array data_type (and not to the
+  legacy 'gpt0' data-type).
+
+
+sc-set-gpt0(<sc-id>) { <int> | <expr> }
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   X  |          X |  X |  X
+
+  This action sets the 32-bit unsigned GPT0 tag according to the sticky counter
+  designated by <sc-id> and the value of <int>/<expr>. The expected result is a
+  boolean. If an error occurs, this action silently fails and the actions
+  evaluation continues. This action is an alias for "sc-set-gpt(0,<sc-id>)".
+  See also the "sc-set-gpt" action.
+
+
+send-spoe-group <engine-name> <group-name>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   X  |   X  |          X |  X |  -
+
+  This action is used to trigger sending of a group of SPOE messages. To do so,
+  the SPOE engine used to send messages must be defined, as well as the SPOE
+  group to send. Of course, the SPOE engine must refer to an existing SPOE
+  filter. If not engine name is provided on the SPOE filter line, the SPOE
+  agent name must be used.
+
+  Arguments:
+    <engine-name>  The SPOE engine name.
+
+    <group-name>   The SPOE group name as specified in the engine
+                   configuration.
+
+
+set-bandwidth-limit <name> [limit {<expr> | <size>}] [period {<expr> | <time>}]
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   X  |   X  |          X |  X |  -
+
+  This action is used to enable the bandwidth limitation filter <name>, either
+  on the upload or download direction depending on the filter type. Custom
+  limit and period may be defined, if and only if <name> references a
+  per-stream bandwidth limitation filter. When a set-bandwidth-limit rule is
+  executed, it first resets all settings of the filter to their defaults prior
+  to enabling it. As a consequence, if several "set-bandwidth-limit" actions
+  are executed for the same filter, only the last one is considered. Several
+  bandwidth limitation filters can be enabled on the same stream.
+
+  Note that this action cannot be used in a defaults section because bandwidth
+  limitation filters cannot be defined in defaults sections. In addition, only
+  the HTTP payload transfer is limited. The HTTP headers are not considered.
+
+  Arguments:
+    <expr>  Is a standard HAProxy expression formed by a sample-fetch followed
+            by some converters. The result is converted to an integer. It is
+            interpreted as a size in bytes for the "limit" parameter and as a
+            duration in milliseconds for the "period" parameter.
+
+    <size>  Is a number. It follows the HAProxy size format and is expressed in
+            bytes.
+
+    <time>  Is a number. It follows the HAProxy time format and is expressed in
+            milliseconds.
+
+  Example:
+    http-request set-bandwidth-limit global-limit
+    http-request set-bandwidth-limit my-limit limit 1m period 10s
+
+  See section 9.7 about bandwidth limitation filter setup.
+
+
+set-dst <expr>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   -  |          X |  - |  -
+
+  This is used to set the destination IP address to the value of specified
+  expression. Useful when a proxy in front of HAProxy rewrites destination IP,
+  but provides the correct IP in a HTTP header; or you want to mask the IP for
+  privacy. If you want to connect to the new address/port, use '0.0.0.0:0' as a
+  server address in the backend.
+
+  Arguments:
+    <expr>  Is a standard HAProxy expression formed by a sample-fetch followed
+            by some converters.
+
+  Example:
+    http-request set-dst hdr(x-dst)
+    http-request set-dst dst,ipmask(24)
+
+  When possible, set-dst preserves the original destination port as long as the
+  address family allows it, otherwise the destination port is set to 0.
+
+
+set-dst-port <expr>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   -  |          X |  - |  -
+
+  This is used to set the destination port address to the value of specified
+  expression. If you want to connect to the new address/port, use '0.0.0.0:0'
+  as a server address in the backend.
+
+  Arguments:
+    <expr>  Is a standard HAProxy expression formed by a sample-fetch
+            followed by some converters.
+
+  Example:
+    http-request set-dst-port hdr(x-port)
+    http-request set-dst-port int(4000)
+
+  When possible, set-dst-port preserves the original destination address as
+  long as the address family supports a port, otherwise it forces the
+  destination address to IPv4 "0.0.0.0" before rewriting the port.
+
+
+set-header <name> <fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  X
+
+  This does the same as the "add-header" action except that the header is first
+  removed if it existed. This is useful when passing security information to
+  the server, where the header must not be manipulated by external users, or to
+  force certain response headers such as "Server" to hide external information.
+  Note that the new value is computed before the removal so it is possible to
+  concatenate a value to an existing header.
+
+  Example:
+        http-request set-header X-Haproxy-Current-Date %T
+        http-request set-header X-SSL                  %[ssl_fc]
+        http-request set-header X-SSL-Session_ID       %[ssl_fc_session_id,hex]
+        http-request set-header X-SSL-Client-Verify    %[ssl_c_verify]
+        http-request set-header X-SSL-Client-DN        %{+Q}[ssl_c_s_dn]
+        http-request set-header X-SSL-Client-CN        %{+Q}[ssl_c_s_dn(cn)]
+        http-request set-header X-SSL-Issuer           %{+Q}[ssl_c_i_dn]
+        http-request set-header X-SSL-Client-NotBefore %{+Q}[ssl_c_notbefore]
+        http-request set-header X-SSL-Client-NotAfter  %{+Q}[ssl_c_notafter]
+
+
+set-log-level <level>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   X  |   X  |          X |  X |  X
+
+  This is used to change the log level of the current request when a certain
+  condition is met. Valid levels are the 8 syslog levels (see the "log"
+  keyword) plus the special level "silent" which disables logging for this
+  request. This rule is not final so the last matching rule wins. This rule
+  can be useful to disable health checks coming from another equipment.
+
+
+set-map(<file-name>) <key fmt> <value fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  X
+
+  This is used to add a new entry into a map. The map must be loaded from a
+  file (even a dummy empty file). The file name of the map to be updated is
+  passed between parentheses. It takes 2 arguments: <key fmt>, which follows
+  log-format rules, used to collect map key, and <value fmt>, which follows
+  log-format rules, used to collect content for the new entry.
+  It performs a lookup in the map before insertion, to avoid duplicated (or
+  more) values. It is the equivalent of the "set map" command from the
+  stats socket, but can be triggered by an HTTP request.
+
+
+set-mark <mark>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   X  |          X |  X |  -
+
+  This is used to set the Netfilter/IPFW MARK on all packets sent to the client
+  to the value passed in <mark> on platforms which support it. This value is an
+  unsigned 32 bit value which can be matched by netfilter/ipfw and by the
+  routing table or monitoring the packets through DTrace. It can be expressed
+  both in decimal or hexadecimal format (prefixed by "0x").
+  This can be useful to force certain packets to take a different route (for
+  example a cheaper network path for bulk downloads). This works on Linux
+  kernels 2.6.32 and above and requires admin privileges, as well on FreeBSD
+  and OpenBSD.
+
+
+set-method <fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  - |  -
+
+  This rewrites the request method with the result of the evaluation of format
+  string <fmt>. There should be very few valid reasons for having to do so as
+  this is more likely to break something than to fix it.
+
+
+set-nice <nice>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   X  |   X  |          X |  X |  -
+
+  This sets the "nice" factor of the current request/response being processed.
+  It only has effect against the other requests being processed at the same
+  time.  The default value is 0, unless altered by the "nice" setting on the
+  "bind" line. The accepted range is -1024..1024. The higher the value, the
+  nicest the request will be. Lower values will make the request more important
+  than other ones. This can be useful to improve the speed of some requests, or
+  lower the priority of non-important requests. Using this setting without
+  prior experimentation can cause some major slowdown.
+
+
+set-path <fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  - |  -
+
+    This rewrites the request path with the result of the evaluation of format
+    string <fmt>. The query string, if any, is left intact. If a scheme and
+    authority is found before the path, they are left intact as well. If the
+    request doesn't have a path ("*"), this one is replaced with the format.
+    This can be used to prepend a directory component in front of a path for
+    example. See also "http-request set-query" and "http-request set-uri".
+
+    Example :
+      # prepend the host name before the path
+      http-request set-path /%[hdr(host)]%[path]
+
+
+set-pathq <fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  - |  -
+
+  This does the same as "http-request set-path" except that the query-string is
+  also rewritten. It may be used to remove the query-string, including the
+  question mark (it is not possible using "http-request set-query").
+
+
+set-priority-class <expr>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   X  |   -  |          X |  - |  -
+
+  This is used to set the queue priority class of the current request.
+  The value must be a sample expression which converts to an integer in the
+  range -2047..2047. Results outside this range will be truncated.
+  The priority class determines the order in which queued requests are
+  processed. Lower values have higher priority.
+
+
+set-priority-offset <expr>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   X  |   -  |          X |  - |  -
+
+  This is used to set the queue priority timestamp offset of the current
+  request. The value must be a sample expression which converts to an integer
+  in the range -524287..524287. Results outside this range will be truncated.
+  When a request is queued, it is ordered first by the priority class, then by
+  the current timestamp adjusted by the given offset in milliseconds. Lower
+  values have higher priority.
+  Note that the resulting timestamp is is only tracked with enough precision
+  for 524,287ms (8m44s287ms). If the request is queued long enough to where the
+  adjusted timestamp exceeds this value, it will be misidentified as highest
+  priority. Thus it is important to set "timeout queue" to a value, where when
+  combined with the offset, does not exceed this limit.
+
+
+set-query <fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  - |  -
+
+  This rewrites the request's query string which appears after the first
+  question mark ("?") with the result of the evaluation of format string <fmt>.
+  The part prior to the question mark is left intact. If the request doesn't
+  contain a question mark and the new value is not empty, then one is added at
+  the end of the URI, followed by the new value. If a question mark was
+  present, it will never be removed even if the value is empty. This can be
+  used to add or remove parameters from the query string.
+
+  See also "http-request set-query" and "http-request set-uri".
+
+  Example:
+    # replace "%3D" with "=" in the query string
+    http-request set-query %[query,regsub(%3D,=,g)]
+
+
+set-src <expr>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   -  |          X |  - |  -
+
+  This is used to set the source IP address to the value of specified
+  expression. Useful when a proxy in front of HAProxy rewrites source IP, but
+  provides the correct IP in a HTTP header; or you want to mask source IP for
+  privacy. All subsequent calls to "src" fetch will return this value
+  (see example).
+
+  Arguments :
+    <expr>  Is a standard HAProxy expression formed by a sample-fetch followed
+            by some converters.
+
+  See also "option forwardfor".
+
+  Example:
+    http-request set-src hdr(x-forwarded-for)
+    http-request set-src src,ipmask(24)
+
+    # After the masking this will track connections
+    # based on the IP address with the last byte zeroed out.
+    http-request track-sc0 src
+
+  When possible, set-src preserves the original source port as long as the
+  address family allows it, otherwise the source port is set to 0.
+
+
+set-src-port <expr>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   -  |          X |  - |  -
+
+  This is used to set the source port address to the value of specified
+  expression.
+
+  Arguments:
+    <expr>  Is a standard HAProxy expression formed by a sample-fetch followed
+            by some converters.
+
+  Example:
+    http-request set-src-port hdr(x-port)
+    http-request set-src-port int(4000)
+
+  When possible, set-src-port preserves the original source address as long as
+  the address family supports a port, otherwise it forces the source address to
+  IPv4 "0.0.0.0" before rewriting the port.
+
+
+set-status <status> [reason <str>]
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          - |  X |  X
+
+  This replaces the response status code with <status> which must be an integer
+  between 100 and 999. Optionally, a custom reason text can be provided defined
+  by <str>, or the default reason for the specified code will be used as a
+  fallback. Note that the reason string only exists in HTTP/1.x and is ignored
+  by other versions of the protocol.
+
+  Example:
+    # return "431 Request Header Fields Too Large"
+    http-response set-status 431
+    # return "503 Slow Down", custom reason
+    http-response set-status 503 reason "Slow Down".
+
+
+set-timeout { client | server | tunnel } { <timeout> | <expr> }
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  -
+
+  This action overrides the specified "client", "server" or "tunnel" timeout
+  for the current stream only. The timeout can be specified in milliseconds or
+  with any other unit if the number is suffixed by the unit as explained at the
+  top of this document. It is also possible to write an expression which must
+  return a number interpreted as a timeout in milliseconds.
+
+  Note that the server/tunnel timeouts are only relevant on the backend side
+  and thus this rule is only available for the proxies with backend
+  capabilities. Likewise, client timeout is only relevant for frontend side.
+  Also the timeout value must be non-null to obtain the expected results.
+
+  Example:
+    http-request set-timeout tunnel 5s
+    http-request set-timeout server req.hdr(host),map_int(host.lst)
+
+  Example:
+    http-response set-timeout tunnel 5s
+    http-response set-timeout server res.hdr(X-Refresh-Seconds),mul(1000)
+
+
+set-tos <tos>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   X  |          X |  X |  -
+
+  This is used to set the TOS or DSCP field value of packets sent to the client
+  to the value passed in <tos> on platforms which support this. This value
+  represents the whole 8 bits of the IP TOS field, and can be expressed both in
+  decimal or hexadecimal format (prefixed by "0x"). Note that only the 6 higher
+  bits are used in DSCP or TOS, and the two lower bits are always 0. This can
+  be used to adjust some routing behavior on border routers based on some
+  information from the request.
+
+  See RFC 2474, 2597, 3260 and 4594 for more information.
+
+
+set-uri <fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  - |  -
+
+  This rewrites the request URI with the result of the evaluation of format
+  string <fmt>. The scheme, authority, path and query string are all replaced
+  at once. This can be used to rewrite hosts in front of proxies, or to perform
+  complex modifications to the URI such as moving parts between the path and
+  the query string. If an absolute URI is set, it will be sent as is to
+  HTTP/1.1 servers. If it is not the desired behavior, the host, the path
+  and/or the query string should be set separately.
+  See also "http-request set-path" and "http-request set-query".
+
+
+set-var(<var-name>[,<cond>...]) <expr>
+set-var-fmt(<var-name>[,<cond>...]) <fmt>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   X  |          X |  X |  X
+
+  This is used to set the contents of a variable. The variable is declared
+  inline.
+
+  Arguments:
+    <var-name>  The name of the variable starts with an indication about its
+                scope. The scopes allowed are:
+                  "proc" : the variable is shared with the whole process
+                  "sess" : the variable is shared with the whole session
+                  "txn"  : the variable is shared with the transaction
+                           (request and response)
+                  "req"  : the variable is shared only during request
+                           processing
+                  "res"  : the variable is shared only during response
+                           processing
+                This prefix is followed by a name. The separator is a '.'.
+                The name may only contain characters 'a-z', 'A-Z', '0-9'
+                and '_'.
+
+    <cond>      A set of conditions that must all be true for the variable to
+                actually be set (such as "ifnotempty", "ifgt" ...). See the
+                set-var converter's description for a full list of possible
+                conditions.
+
+    <expr>      Is a standard HAProxy expression formed by a sample-fetch
+                followed by some converters.
+
+    <fmt>       This is the value expressed using log-format rules (see Custom
+                Log Format in section 8.2.4).
+
+  All scopes are usable for HTTP rules, but scopes "proc" and "sess" are the
+  only usable ones in rule sets which do not have access to contents such as
+  "tcp-request connection" and "tcp-request session".
+
+  Example:
+    http-request set-var(req.my_var) req.fhdr(user-agent),lower
+    http-request set-var-fmt(txn.from) %[src]:%[src_port]
+
+
+silent-drop [ rst-ttl <ttl> ]
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   X  |          X |  X |  -
+
+  This stops the evaluation of the rules and makes the client-facing connection
+  suddenly disappear using a system-dependent way that tries to prevent the
+  client from being notified. When called without the rst-ttl argument,
+  we try to prevent sending any FIN or RST packet back to the client by
+  using TCP_REPAIR. If this fails (mainly because of missing privileges),
+  we fall back to sending a RST packet with a TTL of 1.
+
+  The effect is that the client still sees an established connection while
+  there is none on HAProxy, saving resources. However, stateful equipment
+  placed between the HAProxy and the client (firewalls, proxies,
+  load balancers) will also keep the established connection in their
+  session tables.
+
+  The optional rst-ttl changes this behaviour: TCP_REPAIR is not used, and an
+  RST packet with a configurable TTL is sent. When set to a reasonable value,
+  the RST packet travels through the local infrastructure, deleting the
+  connection in firewalls and other systems, but disappears before reaching
+  the client. Future packets from the client will then be dropped already by
+  front equipments. These local RSTs protect local resources, but not the
+  client's. This must not be used unless the consequences of doing this are
+  fully understood.
+
+
+strict-mode { on | off }
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  X
+
+  This enables or disables the strict rewriting mode for following rules. It
+  does not affect rules declared before it and it is only applicable on rules
+  performing a rewrite on the requests. When the strict mode is enabled, any
+  rewrite failure triggers an internal error. Otherwise, such errors are
+  silently ignored. The purpose of the strict rewriting mode is to make some
+  rewrites optional while others must be performed to continue the request
+  processing.
+
+  By default, the strict rewriting mode is enabled. Its value is also reset
+  when a ruleset evaluation ends. So, for instance, if you change the mode on
+  the frontend, the default mode is restored when HAProxy starts the backend
+  rules evaluation.
+
+
+switch-mode http [ proto <name> ]
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   X  |   -  |          - |  - |  -
+
+  This action is used to perform a connection upgrade. Only HTTP upgrades are
+  supported for now. The protocol may optionally be specified. This action is
+  only available for a proxy with the frontend capability. The connection
+  upgrade is immediately performed, following "tcp-request content" rules are
+  not evaluated. This upgrade method should be preferred to the implicit one
+  consisting to rely on the backend mode. When used, it is possible to set HTTP
+  directives in a frontend without any warning. These directives will be
+  conditionally evaluated if the HTTP upgrade is performed. However, an HTTP
+  backend must still be selected. It remains unsupported to route an HTTP
+  connection (upgraded or not) to a TCP server.
+
+  See section 4 about Proxies for more details on HTTP upgrades.
+
+
+tarpit [ { status | deny_status } <code>] [content-type <type>]
+       [ { default-errorfiles | errorfile <file> | errorfiles <name> |
+           file <file> | lf-file <file> | string <str> | lf-string <fmt> } ]
+       [ hdr <name> <fmt> ]*
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  - |  -
+
+  This stops the evaluation of the rules and immediately blocks the request
+  without responding for a delay specified by "timeout tarpit" or
+  "timeout connect" if the former is not set. After that delay, if the client
+  is still connected, a response is returned so that the client does not
+  suspect it has been tarpitted. Logs will report the flags "PT". The goal of
+  the tarpit rule is to slow down robots during an attack when they're limited
+  on the number of concurrent requests. It can be very efficient against very
+  dumb robots, and will significantly reduce the load on firewalls compared to
+  a "deny" rule. But when facing "correctly" developed robots, it can make
+  things worse by forcing HAProxy and the front firewall to support insane
+  number of concurrent connections. By default an HTTP error 500 is returned.
+  But the response may be customized using same syntax than
+  "http-request return" rules. Thus, see "http-request return" for details.
+
+  For compatibility purpose, when no argument is defined, or only "deny_status",
+  the argument "default-errorfiles" is implied. It means
+  "http-request tarpit [deny_status <status>]" is an alias of
+  "http-request tarpit [status <status>] default-errorfiles".
+  No further "http-request" rules are evaluated.
+  See also "http-request return" and "http-request silent-drop".
+
+
+track-sc0 <key> [table <table>]
+track-sc1 <key> [table <table>]
+track-sc2 <key> [table <table>]
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   -  |          X |  X |  -
+
+  This enables tracking of sticky counters from current request. These rules do
+  not stop evaluation and do not change default action. The number of counters
+  that may be simultaneously tracked by the same connection is set by the
+  global "tune.stick-counters" setting, which defaults to MAX_SESS_STKCTR if
+  set at build time (it is reported in haproxy -vv) and which defaults to 3,
+  so the track-sc number is between 0 and (tune.stick-counters-1). The first
+  "track-sc0" rule executed enables tracking of the counters of the specified
+  table as the first set. The first "track-sc1" rule executed enables tracking
+  of the counters of the specified table as the second set. The first
+  "track-sc2" rule executed enables tracking of the counters of the specified
+  table as the third set. It is a recommended practice to use the first set of
+  counters for the per-frontend counters and the second set for the per-backend
+  ones. But this is just a guideline, all may be used everywhere.
+
+  Arguments :
+
+    <key>   is mandatory, and is a sample expression rule as described in
+            section 7.3. It describes what elements of the incoming connection,
+            request or reponse will be analyzed, extracted, combined, and used
+            to select which table entry to update the counters.
+
+    <table> is an optional table to be used instead of the default one, which
+            is the stick-table declared in the current proxy. All the counters
+            for the matches and updates for the key will then be performed in
+            that table until the session ends.
+
+  Once a "track-sc*" rule is executed, the key is looked up in the table and if
+  it is not found, an entry is allocated for it. Then a pointer to that entry
+  is kept during all the session's life, and this entry's counters are updated
+  as often as possible, every time the session's counters are updated, and also
+  systematically when the session ends. Counters are only updated for events
+  that happen after the tracking has been started. As an exception, connection
+  counters and request counters are systematically updated so that they reflect
+  useful information.
+
+  If the entry tracks concurrent connection counters, one connection is counted
+  for as long as the entry is tracked, and the entry will not expire during
+  that time. Tracking counters also provides a performance advantage over just
+  checking the keys, because only one table lookup is performed for all ACL
+  checks that make use of it.
+
+
+unset-var(<var-name>)
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    X  |   X  |   X  |   X  |          X |  X |  X
+
+  This is used to unset a variable. See the "set-var" action for details about
+  <var-name>.
+
+  Example:
+    http-request unset-var(req.my_var)
+
+
+use-service <service-name>
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   X  |   -  |          X |  - |  -
+
+  This action executes the configured TCP or HTTP service to reply to the
+  request, depending on the rule set it's used in. The rule is final, i.e.
+  no further rules are evaluated in the same rule set.
+
+  A service may choose to reply by sending any valid response or it may
+  immediately close the connection without sending any response. For HTTP
+  services, a valid response requires a valid HTTP response. Outside natives
+  services, for instance the Prometheus exporter for HTTP services, it is
+  possible to write custom TCP and HTTP services in Lua.
+
+  Arguments :
+    <service-name>  is mandatory. It is the service to call
+
+  Example:
+    http-request use-service prometheus-exporter if { path /metrics }
+
+
+wait-for-body time <time> [ at-least <bytes> ]
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  X |  -
+
+  This will delay the processing of the request or response waiting for the
+  payload for at most <time> milliseconds. if "at-least" argument is specified,
+  HAProxy stops waiting for the payload when the first <bytes> bytes are
+  received. 0 means no limit, it is the default value. Regardless the
+  "at-least" argument value, HAProxy stops to wait if the whole payload is
+  received or if the request buffer is full.  This action may be used as a
+  replacement to "option http-buffer-request".
+
+  Arguments :
+
+    <time>    is mandatory. It is the maximum time to wait for the body. It
+              follows the HAProxy time format and is expressed in milliseconds.
+
+    <bytes>   is optional. It is the minimum payload size to receive to stop to
+              wait. It follows the HAProxy size format and is expressed in
+              bytes.
+
+  Example:
+    http-request wait-for-body time 1s at-least 1k if METH_POST
+
+  See also : "option http-buffer-request"
+
+
+wait-for-handshake
+  Usable in:  TCP RqCon| RqSes| RqCnt| RsCnt|    HTTP Req| Res| Aft
+                    -  |   -  |   -  |   -  |          X |  - |  -
+
+  This will delay the processing of the request until the SSL handshake
+  happened. This is mostly useful to delay processing early data until we're
+  sure they are valid.
+
+
 5. Bind and server options
 --------------------------