diff --git a/doc/configuration.txt b/doc/configuration.txt
index c2ad7f9ee..d2d7e2cfe 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -52,21 +52,11 @@ Summary
 2.9.3.        Protocol prefixes
 2.10.     Examples
 
-3.    Global parameters
+3.    Global section
 3.1.      Process management and security
 3.2.      Performance tuning
 3.3.      Debugging
-3.3.1.    Traces
-3.4.      Userlists
-3.5.      Mailers
-3.6.      Programs (deprecated)
-3.7.      HTTP-errors
-3.8.      Rings
-3.9.      Log forwarding
-3.10.     HTTPClient tuning
-3.11.     Certificate Storage
-3.11.1.       Load options
-3.12.     ACME
+3.4.      HTTPClient tuning
 
 4.    Proxies
 4.1.      Proxy keywords matrix
@@ -149,6 +139,18 @@ Summary
 11.1.     Stick-tables declaration
 11.2.     Peers declaration
 
+12.   Other sections
+12.1.     Traces
+12.2.     Userlists
+12.3.     Mailers
+12.4.     HTTP-errors
+12.5.     Rings
+12.6.     Log forwarding
+12.7.     Certificate Storage
+12.7.1.      Load options
+12.8.     ACME
+12.9.     Programs (deprecated)
+
 
 1. Quick reminder about HTTP
 ----------------------------
@@ -938,7 +940,7 @@ existing variables, not empty ones.
       user "$HAPROXY_USER"
 
 Some variables are defined by HAProxy, they can be used in the configuration
-file, or could be inherited by a program (See 3.6. Programs). These variables
+file, or could be inherited by a program (See 12.9. Programs). These variables
 are listed in the matrix below, and they are classified among four categories:
 
   * usable: the variable is accessible from the configuration, either to be
@@ -953,7 +955,7 @@ are listed in the matrix below, and they are classified among four categories:
     described in section 9.3 "Unix Sockets commands" of the management guide.
 
   * exported: variable is exported to launch programs in a modified environment
-    (See section 3.6 "Programs"). Note that this does not apply to external
+    (See section 12.9 "Programs"). Note that this does not apply to external
     checks which have their own rules regarding exported variables.
 
 There also two subcategories "master" and "worker", respectively marked 'M' and
@@ -5197,518 +5199,8 @@ zero-warning
   report errors in such a case. This option is equivalent to command line
   argument "-dW".
 
-3.3.1. Traces
--------------
-
-For debugging purpose, it is possible to activate traces on an HAProxy's
-subsystem. This will dump debug messages about a specific subsystem. It is a
-very powerful tool to diagnose issues. Traces can be dynamically configured via
-the CLI. It is also possible to predefined some settings in the configuration
-file, in dedicated "traces" sections. More details about traces can be found in
-the management guide. It remains a developer tools used during complex
-debugging sessions.  It is pretty verbose and have a cost, so use it with
-caution. And because it is a developer tool, there is no warranty about the
-backward compatibility of this section.
-
-traces
-  Starts a new traces section. One or multiple "traces" section may be
-  used. All direcitives are evaluated in the declararion order, the last ones
-  overriding previous ones.
-
-trace <source> <args...>
-  Configures on "trace" subsystem. Each of them can be found in the management
-  manual, and follow the exact same syntax. Any output that the "trace"
-  command would produce will be emitted during the parsing step of the
-  section. Most of the time these will be errors and warnings, but certain
-  incomplete commands might list permissible choices. This command is not meant
-  for regular use, it will generally only be suggested by developers along
-  complex debugging sessions. It is important to keep in mind that depending on
-  the trace level and details, enabling traces can severely degrade the global
-  performance. Please refer to the management manual for the statements syntax.
-
-  Example:
-    ring buf1
-      size 10485760 # 10MB
-      format timed
-      backing-file /tmp/h1.traces
-
-    ring buf2
-      size 10485760 # 10MB
-      format timed
-      backing-file /tmp/h2.traces
-
-    traces
-      trace h1 sink buf1 level developer verbosity complete start now
-      trace h2 sink buf1 level developer verbosity complete start now
-
-3.4. Userlists
---------------
-It is possible to control access to frontend/backend/listen sections or to
-http stats by allowing only authenticated and authorized users. To do this,
-it is required to create at least one userlist and to define users.
-
-userlist <listname>
-  Creates new userlist with name <listname>. Many independent userlists can be
-  used to store authentication & authorization data for independent customers.
-
-group <groupname> [users <user>,<user>,(...)]
-  Adds group <groupname> to the current userlist. It is also possible to
-  attach users to this group by using a comma separated list of names
-  proceeded by "users" keyword.
-
-user <username> [password|insecure-password <password>]
-                [groups <group>,<group>,(...)]
-  Adds user <username> to the current userlist. Both secure (encrypted) and
-  insecure (unencrypted) passwords can be used. Encrypted passwords are
-  evaluated using the crypt(3) function, so depending on the system's
-  capabilities, different algorithms are supported. For example, modern Glibc
-  based Linux systems support MD5, SHA-256, SHA-512, and, of course, the
-  classic DES-based method of encrypting passwords.
-
-  Attention: Be aware that using encrypted passwords might cause significantly
-  increased CPU usage, depending on the number of requests, and the algorithm
-  used. For any of the hashed variants, the password for each request must
-  be processed through the chosen algorithm, before it can be compared to the
-  value specified in the config file. Most current algorithms are deliberately
-  designed to be expensive to compute to achieve resistance against brute
-  force attacks. They do not simply salt/hash the clear text password once,
-  but thousands of times. This can quickly become a major factor in HAProxy's
-  overall CPU consumption, and can even lead to application crashes!
-
-  To address the high CPU usage of hash functions, one approach is to reduce
-  the number of rounds of the hash function (SHA family algorithms) or decrease
-  the "cost" of the function, if the algorithm supports it.
-
-  As a side note, musl (e.g. Alpine Linux) implementations are known to be
-  slower than their glibc counterparts when calculating hashes, so you might
-  want to consider this aspect too.
-
-  Example:
-        userlist L1
-          group G1 users tiger,scott
-          group G2 users xdb,scott
-
-          user tiger password $6$k6y3o.eP$JlKBx9za9667qe4(...)xHSwRv6J.C0/D7cV91
-          user scott insecure-password elgato
-          user xdb insecure-password hello
-
-        userlist L2
-          group G1
-          group G2
-
-          user tiger password $6$k6y3o.eP$JlKBx(...)xHSwRv6J.C0/D7cV91 groups G1
-          user scott insecure-password elgato groups G1,G2
-          user xdb insecure-password hello groups G2
-
-  Please note that both lists are functionally identical.
-
-
-3.5. Mailers
-------------
-It is possible to send email alerts when the state of servers changes.
-If configured email alerts are sent to each mailer that is configured
-in a mailers section. Email is sent to mailers through Lua (see
-examples/lua/mailers.lua).
-
-mailers <mailersect>
-  Creates a new mailer list with the name <mailersect>. It is an
-  independent section which is referenced by one or more proxies.
-
-mailer <mailername> <ip>:<port>
-  Defines a mailer inside a mailers section.
-
-  Example:
-    global
-        # mailers.lua file as provided in the git repository
-        # adjust path as needed
-        lua-load examples/lua/mailers.lua
-
-    mailers mymailers
-        mailer smtp1 192.168.0.1:587
-        mailer smtp2 192.168.0.2:587
-
-    backend mybackend
-        mode tcp
-        balance roundrobin
-
-        email-alert mailers mymailers
-        email-alert from test1@horms.org
-        email-alert to test2@horms.org
-
-        server srv1 192.168.0.30:80
-        server srv2 192.168.0.31:80
-
-timeout mail <time>
-  Defines the time available for a mail/connection to be made and send to
-  the mail-server. If not defined the default value is 10 seconds. To allow
-  for at least two SYN-ACK packets to be send during initial TCP handshake it
-  is advised to keep this value above 4 seconds.
-
-  Example:
-    mailers mymailers
-        timeout mail 20s
-        mailer smtp1 192.168.0.1:587
-
-3.6. Programs (deprecated)
---------------------------
-
-This section is deprecated and should disappear with HAProxy 3.3. The section
-could be replaced easily by separated process managers. Systemd unit files or
-sysvinit scripts could replace this section as they are more reliable. In docker
-environments, some alternatives can also be found such as s6 or supervisord.
-
-In master-worker mode, it is possible to launch external binaries with the
-master, these processes are called programs. These programs are launched and
-managed the same way as the workers.
-
-Since version 3.1, the program section has a slightly different behavior, the
-section is parsed and the program is started from the master, but the rest of
-the configuration is loaded in the worker. This mean the program configuration
-is completely separated from the worker configuration, and a program could be
-reexecuted even if the worker configuration is wrong upon a reload.
-
-During a reload of HAProxy, those processes are dealing with the same
-sequence as a worker:
-
-  - the master is re-executed
-  - the master sends a SIGUSR1 signal to the program
-  - if "option start-on-reload" is not disabled, the master launches a new
-    instance of the program
-
-During a stop, or restart, a SIGTERM is sent to the programs.
-
-program <name>
-  This is a new program section, this section will create an instance <name>
-  which is visible in "show proc" on the master CLI. (See "9.4. Master CLI" in
-  the management guide).
-
-command <command> [arguments*]
-  Define the command to start with optional arguments. The command is looked
-  up in the current PATH if it does not include an absolute path. This is a
-  mandatory option of the program section. Arguments containing spaces must
-  be enclosed in quotes or double quotes or be prefixed by a backslash.
-
-user <user name>
-  Changes the executed command user ID to the <user name> from /etc/passwd.
-  See also "group".
-
-group <group name>
-  Changes the executed command group ID to the <group name> from /etc/group.
-  See also "user".
-
-option start-on-reload
-no option start-on-reload
-  Start (or not) a new instance of the program upon a reload of the master.
-  The default is to start a new instance. This option may only be used in a
-  program section.
-
-
-3.7. HTTP-errors
-----------------
-
-It is possible to globally declare several groups of HTTP errors, to be
-imported afterwards in any proxy section. Same group may be referenced at
-several places and can be fully or partially imported.
-
-http-errors <name>
-  Create a new http-errors group with the name <name>. It is an independent
-  section that may be referenced by one or more proxies using its name.
-
-errorfile <code> <file>
-  Associate a file contents to an HTTP error code
-
-  Arguments :
-    <code>    is the HTTP status code. Currently, HAProxy is capable of
-              generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410,
-              425, 429, 500, 501, 502, 503, and 504.
-
-    <file>    designates a file containing the full HTTP response. It is
-              recommended to follow the common practice of appending ".http" to
-              the filename so that people do not confuse the response with HTML
-              error pages, and to use absolute paths, since files are read
-              before any chroot is performed.
-
-  Please referrers to "errorfile" keyword in section 4 for details.
-
-  Example:
-    http-errors website-1
-        errorfile 400 /etc/haproxy/errorfiles/site1/400.http
-        errorfile 404 /etc/haproxy/errorfiles/site1/404.http
-        errorfile 408 /dev/null  # work around Chrome pre-connect bug
-
-    http-errors website-2
-        errorfile 400 /etc/haproxy/errorfiles/site2/400.http
-        errorfile 404 /etc/haproxy/errorfiles/site2/404.http
-        errorfile 408 /dev/null  # work around Chrome pre-connect bug
-
-3.8. Rings
-----------
-
-It is possible to globally declare ring-buffers, to be used as target for log
-servers or traces.
-
-ring <ringname>
-  Creates a new ring-buffer with name <ringname>.
-
-backing-file <path>
-  This replaces the regular memory allocation by a RAM-mapped file to store the
-  ring. This can be useful for collecting traces or logs for post-mortem
-  analysis, without having to attach a slow client to the CLI. Newer contents
-  will automatically replace older ones so that the latest contents are always
-  available. The contents written to the ring will be visible in that file once
-  the process stops (most often they will even be seen very soon after but
-  there is no such guarantee since writes are not synchronous).
-
-  When this option is used, the total storage area is reduced by the size of
-  the "struct ring" that starts at the beginning of the area, and that is
-  required to recover the area's contents. The file will be created with the
-  starting user's ownership, with mode 0600 and will be of the size configured
-  by the "size" directive. When the directive is parsed (thus even during
-  config checks), any existing non-empty file will first be renamed with the
-  extra suffix ".bak", and any previously existing file with suffix ".bak" will
-  be removed. This ensures that instant reload or restart of the process will
-  not wipe precious debugging information, and will leave time for an admin to
-  spot this new ".bak" file and to archive it if needed. As such, after a crash
-  the file designated by <path> will contain the freshest information, and if
-  the service is restarted, the "<path>.bak" file will have it instead. This
-  means that the total storage capacity required will be double of the ring
-  size. Failures to rotate the file are silently ignored, so placing the file
-  into a directory without write permissions will be sufficient to avoid the
-  backup file if not desired.
-
-  WARNING: there are stability and security implications in using this feature.
-  First, backing the ring to a slow device (e.g. physical hard drive) may cause
-  perceptible slowdowns during accesses, and possibly even panics if too many
-  threads compete for accesses. Second, an external process modifying the area
-  could cause the haproxy process to crash or to overwrite some of its own
-  memory with traces. Third, if the file system fills up before the ring,
-  writes to the ring may cause the process to crash.
-
-  The information present in this ring are structured and are NOT directly
-  readable using a text editor (even though most of it looks barely readable).
-  The output of this file is only intended for developers.
-
-description <text>
-  The description is an optional description string of the ring. It will
-  appear on CLI. By default, <name> is reused to fill this field.
-
-format <format>
-  Format used to store events into the ring buffer.
-
-  Arguments:
-    <format> is the log format used when generating syslog messages. It may be
-             one of the following :
-
-      iso     A message containing only the ISO date, followed by the text.
-              The PID, process name and system name are omitted. This is
-              designed to be used with a local log server.
-
-      local   Analog to rfc3164 syslog message format except that hostname
-              field is stripped. This is the default.
-              Note: option "log-send-hostname" switches the default to
-              rfc3164.
-
-      raw     A message containing only the text. The level, PID, date, time,
-              process name and system name are omitted. This is designed to be
-              used in containers or during development, where the severity
-              only depends on the file descriptor used (stdout/stderr). This
-              is the default.
-
-      rfc3164 The RFC3164 syslog message format.
-              (https://tools.ietf.org/html/rfc3164)
-
-      rfc5424 The RFC5424 syslog message format.
-              (https://tools.ietf.org/html/rfc5424)
-
-      short   A message containing only a level between angle brackets such as
-              '<3>', followed by the text. The PID, date, time, process name
-              and system name are omitted. This is designed to be used with a
-              local log server. This format is compatible with what the systemd
-              logger consumes.
-
-     priority A message containing only a level plus syslog facility between angle
-              brackets such as '<63>', followed by the text. The PID, date, time,
-              process name and system name are omitted. This is designed to be used
-              with a local log server.
-
-      timed   A message containing only a level between angle brackets such as
-              '<3>', followed by ISO date and by the text. The PID, process
-              name and system name are omitted. This is designed to be
-              used with a local log server.
-
-maxlen <length>
-  The maximum length of an event message stored into the ring,
-  including formatted header. If an event message is longer than
-  <length>, it will be truncated to this length.
-
-server <name> <address> [param*]
-  Used to configure a syslog tcp server to forward messages from ring buffer.
-  This supports for all "server" parameters found in 5.2 paragraph. Some of
-  these parameters are irrelevant for "ring" sections. Important point: there
-  is little reason to add more than one server to a ring, because all servers
-  will receive the exact same copy of the ring contents, and as such the ring
-  will progress at the speed of the slowest server. If one server does not
-  respond, it will prevent old messages from being purged and may block new
-  messages from being inserted into the ring. The proper way to send messages
-  to multiple servers is to use one distinct ring per log server, not to
-  attach multiple servers to the same ring. Note that specific server directive
-  "log-proto" is used to set the protocol used to send messages.
-
-size <size>
-  This is the optional size in bytes for the ring-buffer. Default value is
-  set to BUFSIZE.
-
-timeout connect <timeout>
-  Set the maximum time to wait for a connection attempt to a server to succeed.
-
-  Arguments :
-    <timeout> is the timeout value specified in milliseconds by default, but
-              can be in any other unit if the number is suffixed by the unit,
-              as explained at the top of this document.
-
-timeout server <timeout>
-  Set the maximum time for pending data staying into output buffer.
-
-  Arguments :
-    <timeout> is the timeout value specified in milliseconds by default, but
-              can be in any other unit if the number is suffixed by the unit,
-              as explained at the top of this document.
-
-  Example:
-    global
-        log ring@myring local7
-
-    ring myring
-        description "My local buffer"
-        format rfc5424
-        maxlen 1200
-        size 32764
-        timeout connect 5s
-        timeout server 10s
-        server mysyslogsrv 127.0.0.1:6514 log-proto octet-count
-
-3.9. Log forwarding
--------------------
-
-It is possible to declare one or multiple log forwarding section,
-HAProxy will forward all received log messages to a log servers list.
-
-log-forward <name>
-  Creates a new log forwarder proxy identified as <name>.
-
-backlog <conns>
-  Give hints to the system about the approximate listen backlog desired size
-  on connections accept.
-
-bind <addr> [param*]
-  Used to configure a stream log listener to receive messages to forward.
-  This supports the "bind" parameters found in 5.1 paragraph including
-  those about ssl but some statements such as "alpn" may be irrelevant for
-  syslog protocol over TCP.
-  Those listeners support both "Octet Counting" and "Non-Transparent-Framing"
-  modes as defined in rfc-6587.
-
-dgram-bind <addr> [param*]
-  Used to configure a datagram log listener to receive messages to forward.
-  Addresses must be in IPv4 or IPv6 form,followed by a port. This supports
-  for some of the "bind" parameters found in 5.1 paragraph among which
-  "interface", "namespace" or "transparent", the other ones being
-  silently ignored as irrelevant for UDP/syslog case.
-
-log global
-log <target> [len <length>] [format <format>] [sample <ranges>:<sample_size>]
-    <facility> [<level> [<minlevel>]]
-  Used to configure target log servers. See more details on proxies
-  documentation.
-  If no format specified, HAProxy tries to keep the incoming log format.
-  Configured facility is ignored, except if incoming message does not
-  present a facility but one is mandatory on the outgoing format.
-  If there is no timestamp available in the input format, but the field
-  exists in output format, HAProxy will use the local date.
-
-  Example:
-    global
-       log stderr format iso local7
-
-    ring myring
-        description "My local buffer"
-        format rfc5424
-        maxlen 1200
-        size 32764
-        timeout connect 5s
-        timeout server 10s
-        # syslog tcp server
-        server mysyslogsrv 127.0.0.1:514 log-proto octet-count
-
-    log-forward sylog-loadb
-        dgram-bind 127.0.0.1:1514
-        bind 127.0.0.1:1514
-        # all messages on stderr
-        log global
-        # all messages on local tcp syslog server
-        log ring@myring local0
-        # load balance messages on 4 udp syslog servers
-        log 127.0.0.1:10001 sample 1:4 local0
-        log 127.0.0.1:10002 sample 2:4 local0
-        log 127.0.0.1:10003 sample 3:4 local0
-        log 127.0.0.1:10004 sample 4:4 local0
-
-maxconn <conns>
-  Fix the maximum number of concurrent connections on a log forwarder.
-  10 is the default.
-
-timeout client <timeout>
-  Set the maximum inactivity time on the client side.
-
-option assume-rfc6587-ntf
-  Directs HAProxy to treat incoming TCP log streams always as using
-  non-transparent framing. This option simplifies the framing logic and ensures
-  consistent handling of messages, particularly useful when dealing with
-  improperly formed starting characters.
-
-option dont-parse-log
-  Enables HAProxy to relay syslog messages without attempting to parse and
-  restructure them, useful for forwarding messages that may not conform to
-  traditional formats. This option should be used with the format raw setting on
-  destination log targets to ensure the original message content is preserved.
-
-option host { replace | fill | keep | append }
-  Set the host strategy that should be used on the log-forward section
-  regarding syslog hostname field for outbound rfc3164 or rfc5424 messages.
-
-      replace If input message already contains a value for the hostname field,
-              we replace it by the source IP address from the sender.
-              If input message doesn't contain a value for the hostname field
-              (ie: '-' as input rfc5424 message or non compliant rfc3164 or
-              rfc5424 message), we use the source IP address from the sender as
-              hostname field.
-
-      fill    If input message already contains a value for the hostname field,
-              we keep it.
-              If input message doesn't contain a value for the hostname field
-              (ie: '-' as input rfc5424 message or non compliant rfc3164 or
-              rfc5424 message), we use the source IP address from the sender as
-              hostname field.
-              (This is the default)
-
-      keep    If input message already contains a value for the hostname field,
-              we keep it.
-              If input message doesn't contain a value for the hostname field,
-              we set it to 'localhost' (rfc3164) or '-' (rfc5424).
-
-      append  If input message already contains a value for the hostname field,
-              we append a comma followed by the IP address from the sender.
-              If input message doesn't contain a value for the hostname field,
-              we use the source IP address from the sender.
-
-  For all options above, if the source IP address from the sender is not
-  available (ie: UNIX/ABNS socket), then the resulting strategy is "keep".
-
-  Note that this option is only relevant for rfc3164 or rfc5424 destination
-  log format. Else setting the option will have no visible effect.
-
-3.10. HTTPClient tuning
------------------------
+3.4. HTTPClient tuning
+----------------------
 
 HTTPClient is an internal HTTP library, it can be used by various subsystems,
 for example in LUA scripts. HTTPClient is not used in the data path, in other
@@ -5776,327 +5268,6 @@ httpclient.timeout.connect <timeout>
   The default value is 5000ms.
 
 
-3.11. Certificate Storage
--------------------------
-
-HAProxy uses an internal storage mechanism to load and store certificates used
-in the configuration. This storage can be configured by using a "crt-store"
-section. It allows to configure certificate definitions and which files should
-be loaded in it. A certificate definition must be written before it is used
-elsewhere in the configuration.
-
-crt-store [<name>]
-
-The "crt-store" takes an optional name in argument. If a name is specified,
-every certificate of this store must be referenced using "@<name>/<crt>" or
-"@<name>/<alias>".
-
-Files in the certificate storage can also be updated dynamically with the CLI.
-See "set ssl cert" in the section 9.3 of the management guide.
-
-
-The following keywords are supported in the "crt-store" section :
-  - crt-base
-  - key-base
-  - load
-
-crt-base <dir>
-  Assigns a default directory to fetch SSL certificates from when a relative
-  path is used with "crt" directives. Absolute locations specified prevail and
-  ignore "crt-base". When used in a crt-store, the crt-base of the global
-  section is ignored.
-
-key-base <dir>
-  Assigns a default directory to fetch SSL private keys from when a relative
-  path is used with "key" directives. Absolute locations specified prevail and
-  ignore "key-base". When used in a crt-store, the key-base of the global
-  section is ignored.
-
-load [crt <filename>] [param*]
-  Load SSL files in the certificate storage. For the parameter list, see section
-  "3.11.1. Load options"
-
-Example:
-
-    crt-store
-        load crt "site1.crt" key "site1.key" ocsp "site1.ocsp" alias "site1"
-        load crt "site2.crt" key "site2.key"
-
-    frontend in2
-        bind *:443 ssl crt "@/site1" crt "site2.crt"
-
-    crt-store web
-        crt-base /etc/ssl/certs/
-        key-base /etc/ssl/private/
-        load crt "site3.crt" alias "site3"
-        load crt "site4.crt" key "site4.key"
-
-    frontend in2
-        bind *:443 ssl crt "@web/site1" crt "site2.crt"  crt "@web/site3" crt "@web/site4.crt"
-
-3.11.1. Load options
---------------------
-
-Load SSL files in the certificate storage. The load keyword can take multiple
-parameters which are listed below. These keywords are also usable in a
-crt-list.
-
-crt <filename>
-  This argument is mandatory, it loads a PEM which must contain the public
-  certificate but could also contain the intermediate certificates and the
-  private key.  If no private key is provided in this file, a key can be provided
-  with the "key" keyword.
-
-acme <string>
-  This option allows to configure the ACME protocol for a given certificate.
-  This is an experimental feature which needs the
-  "expose-experimental-directives" keyword in the global section.
-
-  See also Section 3.12 ("ACME") and "domains" in this section.
-
-alias <string>
-  Optional argument. Allow to name the certificate with an alias, so it can be
-  referenced with it in the configuration. An alias must be prefixed with '@/'
-  when called elsewhere in the configuration.
-
-domains <string>
-  Configure the list of domains that will be used for ACME certificates. The
-  first domain of the list is used as the CN. Domains are separated by commas in the list.
-
-  See also Section 3.12 ("ACME") and "acme" in this section.
-
-  Example:
-
-    load crt "example.com.pem" acme LE domains "bar.example.com,foo.example.com"
-
-key <filename>
-  This argument is optional. Load a private key in PEM format. If a private key
-  was already defined in "crt", it will overwrite it.
-
-ocsp <filename>
-  This argument is optional, it loads an OCSP response in DER format. It can
-  be updated with the CLI.
-
-issuer <filename>
-  This argument is optional. Load the OCSP issuer in PEM format. In order to
-  identify which certificate an OCSP Response applies to, the issuer's
-  certificate is necessary.  If the issuer's certificate is not found in the
-  "crt" file, it could be loaded from a file with this argument.
-
-sctl <filename>
-  This argument is optional. Support for Certificate Transparency (RFC6962) TLS
-  extension is enabled. The file must contain a valid Signed Certificate
-  Timestamp List, as described in RFC. File is parsed to check basic syntax,
-  but no signatures are verified.
-
-ocsp-update [ off | on ]
-  Enable automatic OCSP response update when set to 'on', disable it otherwise.
-  Its value defaults to 'off'.
-  To enable the OCSP auto update on a bind line, you can use this option in a
-  crt-store or you can use the global option "tune.ocsp-update.mode".
-  If a given certificate is used in multiple crt-lists with different values of
-  the 'ocsp-update' set, an error will be raised. Likewise, if a certificate
-  inherits from the global option on a bind line and has an incompatible
-  explicit 'ocsp-update' option set in a crt-list, the same error will be
-  raised.
-
-  Examples:
-
-  Here is an example configuration enabling it with a crt-list:
-
-  haproxy.cfg:
-      frontend fe
-          bind :443 ssl crt-list haproxy.list
-
-  haproxy.list:
-      server_cert.pem [ocsp-update on] foo.bar
-
-  Here is an example configuration enabling it with a crt-store:
-
-  haproxy.cfg:
-
-      crt-store
-        load crt foobar.pem ocsp-update on
-
-      frontend fe
-          bind :443 ssl crt foobar.pem
-
-  When the option is set to 'on', we will try to get an ocsp response whenever
-  an ocsp uri is found in the frontend's certificate. The only limitation of
-  this mode is that the certificate's issuer will have to be known in order for
-  the OCSP certid to be built.
-  Each OCSP response will be updated at least once an hour, and even more
-  frequently if a given OCSP response has an expire date earlier than this one
-  hour limit. A minimum update interval of 5 minutes will still exist in order
-  to avoid updating too often responses that have a really short expire time or
-  even no 'Next Update' at all. Because of this hard limit, please note that
-  when auto update is set to 'on', any OCSP response loaded during init will
-  not be updated until at least 5 minutes, even if its expire time ends before
-  now+5m. This should not be too much of a hassle since an OCSP response must
-  be valid when it gets loaded during init (its expire time must be in the
-  future) so it is unlikely that this response expires in such a short time
-  after init.
-  On the other hand, if a certificate has an OCSP uri specified and no OCSP
-  response, setting this option to 'on' for the given certificate will ensure
-  that the OCSP response gets fetched automatically right after init.
-  The default minimum and maximum delays (5 minutes and 1 hour respectively)
-  can be configured by the "ocsp-update.maxdelay" and "ocsp-update.mindelay"
-  global options.
-
-  Whenever an OCSP response is updated by the auto update task or following a
-  call to the "update ssl ocsp-response" CLI command, a dedicated log line is
-  emitted. It follows a dedicated format that contains the following header
-  "<OCSP-UPDATE>" and is followed by specific OCSP-related information:
-    - the path of the corresponding frontend certificate
-    - a numerical update status
-    - a textual update status
-    - the number of update failures for the given response
-    - the number of update successes for the givan response
-  See "show ssl ocsp-updates" CLI command for a full list of error codes and
-  error messages. This line is emitted regardless of the success or failure of
-  the concerned OCSP response update.
-  The OCSP request/response is sent and received through an http_client
-  instance that has the dontlog-normal option set and that uses the regular
-  HTTP log format in case of error (unreachable OCSP responder for instance).
-  If such an error occurs, another log line that contains HTTP-related
-  information will then be emitted alongside the "regular" OCSP one (which will
-  likely have "HTTP error" as text status). But if a purely HTTP error happens
-  (unreachable OCSP responder for instance), an extra log line that follows the
-  regular HTTP log-format will be emitted.
-  Here are two examples of such log lines, with a successful OCSP update log
-  line first and then an example of an HTTP error with the two different lines
-  (lines were spit and the URL was shortened for readability):
-    <133>Mar  6 11:16:53 haproxy[14872]: <OCSP-UPDATE> /path_to_cert/foo.pem 1 \
-            "Update successful" 0 1
-
-    <133>Mar  6 11:18:55 haproxy[14872]: <OCSP-UPDATE> /path_to_cert/bar.pem 2 \
-            "HTTP error" 1 0
-    <133>Mar  6 11:18:55 haproxy[14872]: -:- [06/Mar/2023:11:18:52.200] \
-            <OCSP-UPDATE> -/- 2/0/-1/-1/3009 503 217 - - SC-- 0/0/0/0/3 0/0 {} \
-            "GET http://127.0.0.1:12345/MEMwQT HTTP/1.1"
-
-  Troubleshooting:
-  A common error that can happen with let's encrypt certificates is if the DNS
-  resolution provides an IPv6 address and your system does not have a valid
-  outgoing IPv6 route. In such a case, you can either create the appropriate
-  route or set the "httpclient.resolvers.prefer ipv4" option in the global
-  section.
-  In case of "OCSP response check failure" error, you might want to check that
-  the issuer certificate that you provided is valid.
-  A more precise error message might also be displayed between parenthesis
-  after the "generic" error message. It can happen for "OCSP response check
-  failure" or "Error during insertion" errors.
-
-3.12. ACME
-----------
-
-acme <name>
-
-The ACME protocol can be configured using the "acme" section. The section takes
-a "<name>" argument, which is used to link a certificate to the section.
-
-The ACME section allows to configure HAProxy as an ACMEv2 client. This feature
-is experimental meaning that "expose-experimental-directives" must be in the
-global section so this can be used.
-
-Current limitations as of 3.2: The feature is limited to the HTTP-01 challenge
-for now. The current HAProxy architecture is a non-blocking model, access to
-the disk is not supposed to be done after the configuration is loaded, because
-it could block the event loop, blocking the traffic on the same thread. Meaning
-that the certificates and keys generated from HAProxy will need to be dumped
-from outside HAProxy using "dump ssl cert" on the stats socket.
-External Account Binding (EAB) is not supported.
-
-The ACME scheduler starts at HAProxy startup, it will loop over the
-certificates and start an ACME renewal task when the notAfter task is past
-curtime + (notAfter - notBefore) / 12, or 7 days if notBefore is not defined.
-The scheduler will then sleep and wakeup after 12 hours.
-It is possible to start manually a renewal task with "acme renew'.
-See also "acme status" in the management guide.
-
-The following keywords are usable in the ACME section:
-
-account-key <filename>
-  Configure the path to the account key. The key need to be generated before
-  launching HAProxy. If no account keyword is used, the acme section will try
-  to load a filename using the section name "<name>.account.key". If the file
-  doesn't exist, HAProxy will generate one, using the parameters from the acme
-  section.
-
-  You can also generate manually an RSA private key with openssl:
-
-    openssl genrsa -out account.key 2048
-
-  Or an ecdsa one:
-
-    openssl ecparam -name secp384r1 -genkey -noout -out account.key
-
-bits <number>
-  Configure the number of bits to generate an RSA certificate. Default to 2048.
-  Setting a too high value can trigger a warning if your machine is not
-  powerful enough. (This can be configured with "warn-blocked-traffic-after"
-  but blocking the traffic too long could trigger the watchdog.)
-
-challenge <string>
-  Takes a challenge type as parameter, this must be HTTP-01 or DNS-01. When not
-  used the default is HTTP-01.
-
-contact <string>
-  The contact email that will be associated to the account key in the CA.
-
-curves <string>
-  When using the ECDSA keytype, configure the curves. The default is P-384.
-
-directory <string>
-  This keyword configures the directory URL for the CA used by this acme
-  section. This keyword is mandatory as there is no default URL.
-
-  Example:
-    directory https://acme-staging-v02.api.letsencrypt.org/directory
-
-keytype <string>
-  Configure the type of key that will be generated. Value can be either "RSA"
-  or "ECDSA". You can also configure the "curves" for ECDSA and the number of
-  "bits" for RSA. By default EC384 keys are generated.
-
-map <map>
-  Configure the map which will be used to store token (key) and thumbprint
-  (value), which is useful to reply to a challenge when there are multiple
-  account used. The acme task will add entries before validating the challenge
-  and will remove the entries at the end of the task.
-
-Example:
-
-  global
-      expose-experimental-directives
-      httpclient.resolvers.prefer ipv4
-
-  frontend in
-      bind *:80
-      bind *:443 ssl
-      http-request return status 200 content-type text/plain lf-string "%[path,field(-1,/)].%[path,field(-1,/),map(virt@acme)]\n" if { path_beg '/.well-known/acme-challenge/' }
-      ssl-f-use crt "foo.example.com.pem.rsa"   acme LE1 domains "foo.example.com.pem,bar.example.com"
-      ssl-f-use crt "foo.example.com.pem.ecdsa" acme LE2 domains "foo.example.com.pem,bar.example.com"
-
-  acme LE1
-      directory https://acme-staging-v02.api.letsencrypt.org/directory
-      account-key /etc/haproxy/letsencrypt.account.key
-      contact john.doe@example.com
-      challenge HTTP-01
-      keytype RSA
-      bits 2048
-      map virt@acme
-
-  acme LE2
-      directory https://acme-staging-v02.api.letsencrypt.org/directory
-      account-key /etc/haproxy/letsencrypt.account.key
-      contact john.doe@example.com
-      challenge HTTP-01
-      keytype ECDSA
-      curves P-384
-      map virt@acme
-
-
 4. Proxies
 ----------
 
@@ -7760,7 +6931,7 @@ errorfiles <name> [<code> ...]
   hand using "errorfile" directives.
 
   See also : "http-error", "errorfile", "errorloc", "errorloc302" ,
-             "errorloc303" and section 3.7 about http-errors.
+             "errorloc303" and section 12.4 about http-errors.
 
   Example :
         errorfiles generic
@@ -7855,7 +7026,7 @@ email-alert from <emailaddr>
   and if so sending email alerts is enabled for the proxy.
 
   See also : "email-alert level", "email-alert mailers",
-             "email-alert myhostname", "email-alert to", section 3.5 about
+             "email-alert myhostname", "email-alert to", section 12.3 about
              mailers.
 
 
@@ -7891,7 +7062,7 @@ email-alert level <level>
 
   See also : "email-alert from", "email-alert mailers",
              "email-alert myhostname", "email-alert to",
-             section 3.5 about mailers.
+             section 12.3 about mailers.
 
 
 email-alert mailers <mailersect>
@@ -7910,7 +7081,7 @@ email-alert mailers <mailersect>
   and if so sending email alerts is enabled for the proxy.
 
   See also : "email-alert from", "email-alert level", "email-alert myhostname",
-             "email-alert to", section 3.5 about mailers.
+             "email-alert to", section 12.3 about mailers.
 
 
 email-alert myhostname <hostname>
@@ -7933,7 +7104,7 @@ email-alert myhostname <hostname>
   for the proxy.
 
   See also : "email-alert from", "email-alert level", "email-alert mailers",
-             "email-alert to", section 3.5 about mailers.
+             "email-alert to", section 12.3 about mailers.
 
 
 email-alert to <emailaddr>
@@ -7953,7 +7124,7 @@ email-alert to <emailaddr>
   and if so sending email alerts is enabled for the proxy.
 
   See also : "email-alert from", "email-alert level", "email-alert mailers",
-             "email-alert myhostname", section 3.5 about mailers.
+             "email-alert myhostname", section 12.3 about mailers.
 
 
 error-log-format <fmt>
@@ -8885,7 +8056,7 @@ http-error status <code> [content-type <type>]
         exists during the request headers parsing or between two transactions.
 
   See also : "errorfile", "errorfiles", "errorloc", "errorloc302",
-             "errorloc303" and section 3.7 about http-errors.
+             "errorloc303" and section 12.4 about http-errors.
 
 
 http-request <action> [options...] [ { if | unless } <condition> ]
@@ -8953,7 +8124,7 @@ http-request <action> [options...] [ { if | unless } <condition> ]
         http-request set-map(map.lst) %[src] %[req.hdr(X-Value)] if setmap value
         http-request del-map(map.lst) %[src]                     if delmap
 
-  See also : "stats http-request", section 3.4 about userlists and section 7
+  See also : "stats http-request", section 12.2 about userlists and section 7
              about ACL usage.
 
 http-response <action> <options...> [ { if | unless } <condition> ]
@@ -9008,7 +8179,7 @@ http-response <action> <options...> [ { if | unless } <condition> ]
     http-response set-map(map.lst) %[src] %[res.hdr(X-Value)] if value
     http-response del-map(map.lst) %[src]                     if ! value
 
-  See also : "http-request", section 3.4 about userlists and section 7 about
+  See also : "http-request", section 12.2 about userlists and section 7 about
              ACL usage.
 
 http-reuse { never | safe | aggressive | always }
@@ -9356,7 +8527,8 @@ no log
                  "show events" command, which will also list existing rings and
                  their sizes. Such buffers are lost on reload or restart but
                  when used as a complement this can help troubleshooting by
-                 having the logs instantly available.
+                 having the logs instantly available. See section 12.5 about
+                 rings.
 
                - A log backend in the form "backend@<name>", which will send
                  log messages to the corresponding log backend responsible for
@@ -12903,7 +12075,7 @@ stats admin { if | unless } <cond>
         stats http-request auth unless AUTH
         stats admin if AUTH_ADMIN
 
-  See also : "stats enable", "stats auth", "stats http-request", section 3.4
+  See also : "stats enable", "stats auth", "stats http-request", section 12.2
              about userlists and section 7 about ACL usage.
 
 ssl-f-use [<sslbindconf> ...]*
@@ -12937,7 +12109,7 @@ ssl-f-use [<sslbindconf> ...]*
     - verify
 
     sslbindconf also supports the following keywords from the crt-store load
-    keyword (see Section 3.11.1. Load options):
+    keyword (see Section 12.7.1. Load options):
 
     - crt
     - key
@@ -13121,7 +12293,7 @@ stats http-request { allow | deny | auth [realm <realm>] }
   There is no fixed limit to the number of http-request statements per
   instance.
 
-  See also : "http-request", section 3.4 about userlists and section 7
+  See also : "http-request", section 12.2 about userlists and section 7
              about ACL usage.
 
 
@@ -17285,7 +16457,7 @@ crt-list <file>
      - verify
 
      <sslbindconf> also supports the following keywords from the crt-store load
-     keyword (see Section 3.11.1. Load options):
+     keyword (see Section 12.7.1. Load options):
 
      - crt
      - key
@@ -30303,6 +29475,847 @@ table <tablename> type {ip | integer | string [len <length>] | binary [len <leng
   "t1" table declared as a backend as "t1" as global name. But at peer protocol
   level the former table is named "/t1", the latter is again named "t1".
 
+12. Other sections
+------------------
+
+The sections described below are less commonly used and usually support only a
+few parameters. There is no implicit relation between any of them. They're all
+started using a single keyword. None of them is permitted before a "global"
+section. The support for some of them might be conditionned by build options
+(e.g. anything SSL-related).
+
+12.1. Traces
+------------
+
+For debugging purpose, it is possible to activate traces on an HAProxy's
+subsystem. This will dump debug messages about a specific subsystem. It is a
+very powerful tool to diagnose issues. Traces can be dynamically configured via
+the CLI. It is also possible to predefined some settings in the configuration
+file, in dedicated "traces" sections. More details about traces can be found in
+the management guide. It remains a developer tools used during complex
+debugging sessions.  It is pretty verbose and have a cost, so use it with
+caution. And because it is a developer tool, there is no warranty about the
+backward compatibility of this section.
+
+traces
+  Starts a new traces section. One or multiple "traces" section may be
+  used. All direcitives are evaluated in the declararion order, the last ones
+  overriding previous ones.
+
+trace <source> <args...>
+  Configures on "trace" subsystem. Each of them can be found in the management
+  manual, and follow the exact same syntax. Any output that the "trace"
+  command would produce will be emitted during the parsing step of the
+  section. Most of the time these will be errors and warnings, but certain
+  incomplete commands might list permissible choices. This command is not meant
+  for regular use, it will generally only be suggested by developers along
+  complex debugging sessions. It is important to keep in mind that depending on
+  the trace level and details, enabling traces can severely degrade the global
+  performance. Please refer to the management manual for the statements syntax.
+
+  Example:
+    ring buf1
+      size 10485760 # 10MB
+      format timed
+      backing-file /tmp/h1.traces
+
+    ring buf2
+      size 10485760 # 10MB
+      format timed
+      backing-file /tmp/h2.traces
+
+    traces
+      trace h1 sink buf1 level developer verbosity complete start now
+      trace h2 sink buf1 level developer verbosity complete start now
+
+12.2. Userlists
+---------------
+
+It is possible to control access to frontend/backend/listen sections or to
+http stats by allowing only authenticated and authorized users. To do this,
+it is required to create at least one userlist and to define users.
+
+userlist <listname>
+  Creates new userlist with name <listname>. Many independent userlists can be
+  used to store authentication & authorization data for independent customers.
+
+group <groupname> [users <user>,<user>,(...)]
+  Adds group <groupname> to the current userlist. It is also possible to
+  attach users to this group by using a comma separated list of names
+  proceeded by "users" keyword.
+
+user <username> [password|insecure-password <password>]
+                [groups <group>,<group>,(...)]
+  Adds user <username> to the current userlist. Both secure (encrypted) and
+  insecure (unencrypted) passwords can be used. Encrypted passwords are
+  evaluated using the crypt(3) function, so depending on the system's
+  capabilities, different algorithms are supported. For example, modern Glibc
+  based Linux systems support MD5, SHA-256, SHA-512, and, of course, the
+  classic DES-based method of encrypting passwords.
+
+  Attention: Be aware that using encrypted passwords might cause significantly
+  increased CPU usage, depending on the number of requests, and the algorithm
+  used. For any of the hashed variants, the password for each request must
+  be processed through the chosen algorithm, before it can be compared to the
+  value specified in the config file. Most current algorithms are deliberately
+  designed to be expensive to compute to achieve resistance against brute
+  force attacks. They do not simply salt/hash the clear text password once,
+  but thousands of times. This can quickly become a major factor in HAProxy's
+  overall CPU consumption, and can even lead to application crashes!
+
+  To address the high CPU usage of hash functions, one approach is to reduce
+  the number of rounds of the hash function (SHA family algorithms) or decrease
+  the "cost" of the function, if the algorithm supports it.
+
+  As a side note, musl (e.g. Alpine Linux) implementations are known to be
+  slower than their glibc counterparts when calculating hashes, so you might
+  want to consider this aspect too.
+
+  Example:
+        userlist L1
+          group G1 users tiger,scott
+          group G2 users xdb,scott
+
+          user tiger password $6$k6y3o.eP$JlKBx9za9667qe4(...)xHSwRv6J.C0/D7cV91
+          user scott insecure-password elgato
+          user xdb insecure-password hello
+
+        userlist L2
+          group G1
+          group G2
+
+          user tiger password $6$k6y3o.eP$JlKBx(...)xHSwRv6J.C0/D7cV91 groups G1
+          user scott insecure-password elgato groups G1,G2
+          user xdb insecure-password hello groups G2
+
+  Please note that both lists are functionally identical.
+
+
+12.3. Mailers
+-------------
+
+It is possible to send email alerts when the state of servers changes.
+If configured email alerts are sent to each mailer that is configured
+in a mailers section. Email is sent to mailers through Lua (see
+examples/lua/mailers.lua).
+
+mailers <mailersect>
+  Creates a new mailer list with the name <mailersect>. It is an
+  independent section which is referenced by one or more proxies.
+
+mailer <mailername> <ip>:<port>
+  Defines a mailer inside a mailers section.
+
+  Example:
+    global
+        # mailers.lua file as provided in the git repository
+        # adjust path as needed
+        lua-load examples/lua/mailers.lua
+
+    mailers mymailers
+        mailer smtp1 192.168.0.1:587
+        mailer smtp2 192.168.0.2:587
+
+    backend mybackend
+        mode tcp
+        balance roundrobin
+
+        email-alert mailers mymailers
+        email-alert from test1@horms.org
+        email-alert to test2@horms.org
+
+        server srv1 192.168.0.30:80
+        server srv2 192.168.0.31:80
+
+timeout mail <time>
+  Defines the time available for a mail/connection to be made and send to
+  the mail-server. If not defined the default value is 10 seconds. To allow
+  for at least two SYN-ACK packets to be send during initial TCP handshake it
+  is advised to keep this value above 4 seconds.
+
+  Example:
+    mailers mymailers
+        timeout mail 20s
+        mailer smtp1 192.168.0.1:587
+
+12.4. HTTP-errors
+-----------------
+
+It is possible to globally declare several groups of HTTP errors, to be
+imported afterwards in any proxy section. Same group may be referenced at
+several places and can be fully or partially imported.
+
+http-errors <name>
+  Create a new http-errors group with the name <name>. It is an independent
+  section that may be referenced by one or more proxies using its name.
+
+errorfile <code> <file>
+  Associate a file contents to an HTTP error code
+
+  Arguments :
+    <code>    is the HTTP status code. Currently, HAProxy is capable of
+              generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410,
+              425, 429, 500, 501, 502, 503, and 504.
+
+    <file>    designates a file containing the full HTTP response. It is
+              recommended to follow the common practice of appending ".http" to
+              the filename so that people do not confuse the response with HTML
+              error pages, and to use absolute paths, since files are read
+              before any chroot is performed.
+
+  Please referrers to "errorfile" keyword in section 4 for details.
+
+  Example:
+    http-errors website-1
+        errorfile 400 /etc/haproxy/errorfiles/site1/400.http
+        errorfile 404 /etc/haproxy/errorfiles/site1/404.http
+        errorfile 408 /dev/null  # work around Chrome pre-connect bug
+
+    http-errors website-2
+        errorfile 400 /etc/haproxy/errorfiles/site2/400.http
+        errorfile 404 /etc/haproxy/errorfiles/site2/404.http
+        errorfile 408 /dev/null  # work around Chrome pre-connect bug
+
+12.5. Rings
+-----------
+
+It is possible to globally declare ring-buffers, to be used as target for log
+servers or traces.
+
+ring <ringname>
+  Creates a new ring-buffer with name <ringname>.
+
+backing-file <path>
+  This replaces the regular memory allocation by a RAM-mapped file to store the
+  ring. This can be useful for collecting traces or logs for post-mortem
+  analysis, without having to attach a slow client to the CLI. Newer contents
+  will automatically replace older ones so that the latest contents are always
+  available. The contents written to the ring will be visible in that file once
+  the process stops (most often they will even be seen very soon after but
+  there is no such guarantee since writes are not synchronous).
+
+  When this option is used, the total storage area is reduced by the size of
+  the "struct ring" that starts at the beginning of the area, and that is
+  required to recover the area's contents. The file will be created with the
+  starting user's ownership, with mode 0600 and will be of the size configured
+  by the "size" directive. When the directive is parsed (thus even during
+  config checks), any existing non-empty file will first be renamed with the
+  extra suffix ".bak", and any previously existing file with suffix ".bak" will
+  be removed. This ensures that instant reload or restart of the process will
+  not wipe precious debugging information, and will leave time for an admin to
+  spot this new ".bak" file and to archive it if needed. As such, after a crash
+  the file designated by <path> will contain the freshest information, and if
+  the service is restarted, the "<path>.bak" file will have it instead. This
+  means that the total storage capacity required will be double of the ring
+  size. Failures to rotate the file are silently ignored, so placing the file
+  into a directory without write permissions will be sufficient to avoid the
+  backup file if not desired.
+
+  WARNING: there are stability and security implications in using this feature.
+  First, backing the ring to a slow device (e.g. physical hard drive) may cause
+  perceptible slowdowns during accesses, and possibly even panics if too many
+  threads compete for accesses. Second, an external process modifying the area
+  could cause the haproxy process to crash or to overwrite some of its own
+  memory with traces. Third, if the file system fills up before the ring,
+  writes to the ring may cause the process to crash.
+
+  The information present in this ring are structured and are NOT directly
+  readable using a text editor (even though most of it looks barely readable).
+  The output of this file is only intended for developers.
+
+description <text>
+  The description is an optional description string of the ring. It will
+  appear on CLI. By default, <name> is reused to fill this field.
+
+format <format>
+  Format used to store events into the ring buffer.
+
+  Arguments:
+    <format> is the log format used when generating syslog messages. It may be
+             one of the following :
+
+      iso     A message containing only the ISO date, followed by the text.
+              The PID, process name and system name are omitted. This is
+              designed to be used with a local log server.
+
+      local   Analog to rfc3164 syslog message format except that hostname
+              field is stripped. This is the default.
+              Note: option "log-send-hostname" switches the default to
+              rfc3164.
+
+      raw     A message containing only the text. The level, PID, date, time,
+              process name and system name are omitted. This is designed to be
+              used in containers or during development, where the severity
+              only depends on the file descriptor used (stdout/stderr). This
+              is the default.
+
+      rfc3164 The RFC3164 syslog message format.
+              (https://tools.ietf.org/html/rfc3164)
+
+      rfc5424 The RFC5424 syslog message format.
+              (https://tools.ietf.org/html/rfc5424)
+
+      short   A message containing only a level between angle brackets such as
+              '<3>', followed by the text. The PID, date, time, process name
+              and system name are omitted. This is designed to be used with a
+              local log server. This format is compatible with what the systemd
+              logger consumes.
+
+     priority A message containing only a level plus syslog facility between angle
+              brackets such as '<63>', followed by the text. The PID, date, time,
+              process name and system name are omitted. This is designed to be used
+              with a local log server.
+
+      timed   A message containing only a level between angle brackets such as
+              '<3>', followed by ISO date and by the text. The PID, process
+              name and system name are omitted. This is designed to be
+              used with a local log server.
+
+maxlen <length>
+  The maximum length of an event message stored into the ring,
+  including formatted header. If an event message is longer than
+  <length>, it will be truncated to this length.
+
+server <name> <address> [param*]
+  Used to configure a syslog tcp server to forward messages from ring buffer.
+  This supports for all "server" parameters found in 5.2 paragraph. Some of
+  these parameters are irrelevant for "ring" sections. Important point: there
+  is little reason to add more than one server to a ring, because all servers
+  will receive the exact same copy of the ring contents, and as such the ring
+  will progress at the speed of the slowest server. If one server does not
+  respond, it will prevent old messages from being purged and may block new
+  messages from being inserted into the ring. The proper way to send messages
+  to multiple servers is to use one distinct ring per log server, not to
+  attach multiple servers to the same ring. Note that specific server directive
+  "log-proto" is used to set the protocol used to send messages.
+
+size <size>
+  This is the optional size in bytes for the ring-buffer. Default value is
+  set to BUFSIZE.
+
+timeout connect <timeout>
+  Set the maximum time to wait for a connection attempt to a server to succeed.
+
+  Arguments :
+    <timeout> is the timeout value specified in milliseconds by default, but
+              can be in any other unit if the number is suffixed by the unit,
+              as explained at the top of this document.
+
+timeout server <timeout>
+  Set the maximum time for pending data staying into output buffer.
+
+  Arguments :
+    <timeout> is the timeout value specified in milliseconds by default, but
+              can be in any other unit if the number is suffixed by the unit,
+              as explained at the top of this document.
+
+  Example:
+    global
+        log ring@myring local7
+
+    ring myring
+        description "My local buffer"
+        format rfc5424
+        maxlen 1200
+        size 32764
+        timeout connect 5s
+        timeout server 10s
+        server mysyslogsrv 127.0.0.1:6514 log-proto octet-count
+
+12.6. Log forwarding
+--------------------
+
+It is possible to declare one or multiple log forwarding section,
+HAProxy will forward all received log messages to a log servers list.
+
+log-forward <name>
+  Creates a new log forwarder proxy identified as <name>.
+
+backlog <conns>
+  Give hints to the system about the approximate listen backlog desired size
+  on connections accept.
+
+bind <addr> [param*]
+  Used to configure a stream log listener to receive messages to forward.
+  This supports the "bind" parameters found in 5.1 paragraph including
+  those about ssl but some statements such as "alpn" may be irrelevant for
+  syslog protocol over TCP.
+  Those listeners support both "Octet Counting" and "Non-Transparent-Framing"
+  modes as defined in rfc-6587.
+
+dgram-bind <addr> [param*]
+  Used to configure a datagram log listener to receive messages to forward.
+  Addresses must be in IPv4 or IPv6 form,followed by a port. This supports
+  for some of the "bind" parameters found in 5.1 paragraph among which
+  "interface", "namespace" or "transparent", the other ones being
+  silently ignored as irrelevant for UDP/syslog case.
+
+log global
+log <target> [len <length>] [format <format>] [sample <ranges>:<sample_size>]
+    <facility> [<level> [<minlevel>]]
+  Used to configure target log servers. See more details on proxies
+  documentation.
+  If no format specified, HAProxy tries to keep the incoming log format.
+  Configured facility is ignored, except if incoming message does not
+  present a facility but one is mandatory on the outgoing format.
+  If there is no timestamp available in the input format, but the field
+  exists in output format, HAProxy will use the local date.
+
+  Example:
+    global
+       log stderr format iso local7
+
+    ring myring
+        description "My local buffer"
+        format rfc5424
+        maxlen 1200
+        size 32764
+        timeout connect 5s
+        timeout server 10s
+        # syslog tcp server
+        server mysyslogsrv 127.0.0.1:514 log-proto octet-count
+
+    log-forward sylog-loadb
+        dgram-bind 127.0.0.1:1514
+        bind 127.0.0.1:1514
+        # all messages on stderr
+        log global
+        # all messages on local tcp syslog server
+        log ring@myring local0
+        # load balance messages on 4 udp syslog servers
+        log 127.0.0.1:10001 sample 1:4 local0
+        log 127.0.0.1:10002 sample 2:4 local0
+        log 127.0.0.1:10003 sample 3:4 local0
+        log 127.0.0.1:10004 sample 4:4 local0
+
+maxconn <conns>
+  Fix the maximum number of concurrent connections on a log forwarder.
+  10 is the default.
+
+timeout client <timeout>
+  Set the maximum inactivity time on the client side.
+
+option assume-rfc6587-ntf
+  Directs HAProxy to treat incoming TCP log streams always as using
+  non-transparent framing. This option simplifies the framing logic and ensures
+  consistent handling of messages, particularly useful when dealing with
+  improperly formed starting characters.
+
+option dont-parse-log
+  Enables HAProxy to relay syslog messages without attempting to parse and
+  restructure them, useful for forwarding messages that may not conform to
+  traditional formats. This option should be used with the format raw setting on
+  destination log targets to ensure the original message content is preserved.
+
+option host { replace | fill | keep | append }
+  Set the host strategy that should be used on the log-forward section
+  regarding syslog hostname field for outbound rfc3164 or rfc5424 messages.
+
+      replace If input message already contains a value for the hostname field,
+              we replace it by the source IP address from the sender.
+              If input message doesn't contain a value for the hostname field
+              (ie: '-' as input rfc5424 message or non compliant rfc3164 or
+              rfc5424 message), we use the source IP address from the sender as
+              hostname field.
+
+      fill    If input message already contains a value for the hostname field,
+              we keep it.
+              If input message doesn't contain a value for the hostname field
+              (ie: '-' as input rfc5424 message or non compliant rfc3164 or
+              rfc5424 message), we use the source IP address from the sender as
+              hostname field.
+              (This is the default)
+
+      keep    If input message already contains a value for the hostname field,
+              we keep it.
+              If input message doesn't contain a value for the hostname field,
+              we set it to 'localhost' (rfc3164) or '-' (rfc5424).
+
+      append  If input message already contains a value for the hostname field,
+              we append a comma followed by the IP address from the sender.
+              If input message doesn't contain a value for the hostname field,
+              we use the source IP address from the sender.
+
+  For all options above, if the source IP address from the sender is not
+  available (ie: UNIX/ABNS socket), then the resulting strategy is "keep".
+
+  Note that this option is only relevant for rfc3164 or rfc5424 destination
+  log format. Else setting the option will have no visible effect.
+
+12.7. Certificate Storage
+-------------------------
+
+HAProxy uses an internal storage mechanism to load and store certificates used
+in the configuration. This storage can be configured by using a "crt-store"
+section. It allows to configure certificate definitions and which files should
+be loaded in it. A certificate definition must be written before it is used
+elsewhere in the configuration.
+
+crt-store [<name>]
+
+The "crt-store" takes an optional name in argument. If a name is specified,
+every certificate of this store must be referenced using "@<name>/<crt>" or
+"@<name>/<alias>".
+
+Files in the certificate storage can also be updated dynamically with the CLI.
+See "set ssl cert" in the section 9.3 of the management guide.
+
+
+The following keywords are supported in the "crt-store" section :
+  - crt-base
+  - key-base
+  - load
+
+crt-base <dir>
+  Assigns a default directory to fetch SSL certificates from when a relative
+  path is used with "crt" directives. Absolute locations specified prevail and
+  ignore "crt-base". When used in a crt-store, the crt-base of the global
+  section is ignored.
+
+key-base <dir>
+  Assigns a default directory to fetch SSL private keys from when a relative
+  path is used with "key" directives. Absolute locations specified prevail and
+  ignore "key-base". When used in a crt-store, the key-base of the global
+  section is ignored.
+
+load [crt <filename>] [param*]
+  Load SSL files in the certificate storage. For the parameter list, see section
+  "12.7.1. Load options"
+
+Example:
+
+    crt-store
+        load crt "site1.crt" key "site1.key" ocsp "site1.ocsp" alias "site1"
+        load crt "site2.crt" key "site2.key"
+
+    frontend in2
+        bind *:443 ssl crt "@/site1" crt "site2.crt"
+
+    crt-store web
+        crt-base /etc/ssl/certs/
+        key-base /etc/ssl/private/
+        load crt "site3.crt" alias "site3"
+        load crt "site4.crt" key "site4.key"
+
+    frontend in2
+        bind *:443 ssl crt "@web/site1" crt "site2.crt"  crt "@web/site3" crt "@web/site4.crt"
+
+12.7.1. Load options
+--------------------
+
+Load SSL files in the certificate storage. The load keyword can take multiple
+parameters which are listed below. These keywords are also usable in a
+crt-list.
+
+crt <filename>
+  This argument is mandatory, it loads a PEM which must contain the public
+  certificate but could also contain the intermediate certificates and the
+  private key.  If no private key is provided in this file, a key can be provided
+  with the "key" keyword.
+
+acme <string>
+  This option allows to configure the ACME protocol for a given certificate.
+  This is an experimental feature which needs the
+  "expose-experimental-directives" keyword in the global section.
+
+  See also Section 12.8 ("ACME") and "domains" in this section.
+
+alias <string>
+  Optional argument. Allow to name the certificate with an alias, so it can be
+  referenced with it in the configuration. An alias must be prefixed with '@/'
+  when called elsewhere in the configuration.
+
+domains <string>
+  Configure the list of domains that will be used for ACME certificates. The
+  first domain of the list is used as the CN. Domains are separated by commas in the list.
+
+  See also Section 12.8 ("ACME") and "acme" in this section.
+
+  Example:
+
+    load crt "example.com.pem" acme LE domains "bar.example.com,foo.example.com"
+
+key <filename>
+  This argument is optional. Load a private key in PEM format. If a private key
+  was already defined in "crt", it will overwrite it.
+
+ocsp <filename>
+  This argument is optional, it loads an OCSP response in DER format. It can
+  be updated with the CLI.
+
+issuer <filename>
+  This argument is optional. Load the OCSP issuer in PEM format. In order to
+  identify which certificate an OCSP Response applies to, the issuer's
+  certificate is necessary.  If the issuer's certificate is not found in the
+  "crt" file, it could be loaded from a file with this argument.
+
+sctl <filename>
+  This argument is optional. Support for Certificate Transparency (RFC6962) TLS
+  extension is enabled. The file must contain a valid Signed Certificate
+  Timestamp List, as described in RFC. File is parsed to check basic syntax,
+  but no signatures are verified.
+
+ocsp-update [ off | on ]
+  Enable automatic OCSP response update when set to 'on', disable it otherwise.
+  Its value defaults to 'off'.
+  To enable the OCSP auto update on a bind line, you can use this option in a
+  crt-store or you can use the global option "tune.ocsp-update.mode".
+  If a given certificate is used in multiple crt-lists with different values of
+  the 'ocsp-update' set, an error will be raised. Likewise, if a certificate
+  inherits from the global option on a bind line and has an incompatible
+  explicit 'ocsp-update' option set in a crt-list, the same error will be
+  raised.
+
+  Examples:
+
+  Here is an example configuration enabling it with a crt-list:
+
+  haproxy.cfg:
+      frontend fe
+          bind :443 ssl crt-list haproxy.list
+
+  haproxy.list:
+      server_cert.pem [ocsp-update on] foo.bar
+
+  Here is an example configuration enabling it with a crt-store:
+
+  haproxy.cfg:
+
+      crt-store
+        load crt foobar.pem ocsp-update on
+
+      frontend fe
+          bind :443 ssl crt foobar.pem
+
+  When the option is set to 'on', we will try to get an ocsp response whenever
+  an ocsp uri is found in the frontend's certificate. The only limitation of
+  this mode is that the certificate's issuer will have to be known in order for
+  the OCSP certid to be built.
+  Each OCSP response will be updated at least once an hour, and even more
+  frequently if a given OCSP response has an expire date earlier than this one
+  hour limit. A minimum update interval of 5 minutes will still exist in order
+  to avoid updating too often responses that have a really short expire time or
+  even no 'Next Update' at all. Because of this hard limit, please note that
+  when auto update is set to 'on', any OCSP response loaded during init will
+  not be updated until at least 5 minutes, even if its expire time ends before
+  now+5m. This should not be too much of a hassle since an OCSP response must
+  be valid when it gets loaded during init (its expire time must be in the
+  future) so it is unlikely that this response expires in such a short time
+  after init.
+  On the other hand, if a certificate has an OCSP uri specified and no OCSP
+  response, setting this option to 'on' for the given certificate will ensure
+  that the OCSP response gets fetched automatically right after init.
+  The default minimum and maximum delays (5 minutes and 1 hour respectively)
+  can be configured by the "ocsp-update.maxdelay" and "ocsp-update.mindelay"
+  global options.
+
+  Whenever an OCSP response is updated by the auto update task or following a
+  call to the "update ssl ocsp-response" CLI command, a dedicated log line is
+  emitted. It follows a dedicated format that contains the following header
+  "<OCSP-UPDATE>" and is followed by specific OCSP-related information:
+    - the path of the corresponding frontend certificate
+    - a numerical update status
+    - a textual update status
+    - the number of update failures for the given response
+    - the number of update successes for the givan response
+  See "show ssl ocsp-updates" CLI command for a full list of error codes and
+  error messages. This line is emitted regardless of the success or failure of
+  the concerned OCSP response update.
+  The OCSP request/response is sent and received through an http_client
+  instance that has the dontlog-normal option set and that uses the regular
+  HTTP log format in case of error (unreachable OCSP responder for instance).
+  If such an error occurs, another log line that contains HTTP-related
+  information will then be emitted alongside the "regular" OCSP one (which will
+  likely have "HTTP error" as text status). But if a purely HTTP error happens
+  (unreachable OCSP responder for instance), an extra log line that follows the
+  regular HTTP log-format will be emitted.
+  Here are two examples of such log lines, with a successful OCSP update log
+  line first and then an example of an HTTP error with the two different lines
+  (lines were spit and the URL was shortened for readability):
+    <133>Mar  6 11:16:53 haproxy[14872]: <OCSP-UPDATE> /path_to_cert/foo.pem 1 \
+            "Update successful" 0 1
+
+    <133>Mar  6 11:18:55 haproxy[14872]: <OCSP-UPDATE> /path_to_cert/bar.pem 2 \
+            "HTTP error" 1 0
+    <133>Mar  6 11:18:55 haproxy[14872]: -:- [06/Mar/2023:11:18:52.200] \
+            <OCSP-UPDATE> -/- 2/0/-1/-1/3009 503 217 - - SC-- 0/0/0/0/3 0/0 {} \
+            "GET http://127.0.0.1:12345/MEMwQT HTTP/1.1"
+
+  Troubleshooting:
+  A common error that can happen with let's encrypt certificates is if the DNS
+  resolution provides an IPv6 address and your system does not have a valid
+  outgoing IPv6 route. In such a case, you can either create the appropriate
+  route or set the "httpclient.resolvers.prefer ipv4" option in the global
+  section.
+  In case of "OCSP response check failure" error, you might want to check that
+  the issuer certificate that you provided is valid.
+  A more precise error message might also be displayed between parenthesis
+  after the "generic" error message. It can happen for "OCSP response check
+  failure" or "Error during insertion" errors.
+
+12.8. ACME
+----------
+
+acme <name>
+
+The ACME protocol can be configured using the "acme" section. The section takes
+a "<name>" argument, which is used to link a certificate to the section.
+
+The ACME section allows to configure HAProxy as an ACMEv2 client. This feature
+is experimental meaning that "expose-experimental-directives" must be in the
+global section so this can be used.
+
+Current limitations as of 3.2: The feature is limited to the HTTP-01 challenge
+for now. The current HAProxy architecture is a non-blocking model, access to
+the disk is not supposed to be done after the configuration is loaded, because
+it could block the event loop, blocking the traffic on the same thread. Meaning
+that the certificates and keys generated from HAProxy will need to be dumped
+from outside HAProxy using "dump ssl cert" on the stats socket.
+External Account Binding (EAB) is not supported.
+
+The ACME scheduler starts at HAProxy startup, it will loop over the
+certificates and start an ACME renewal task when the notAfter task is past
+curtime + (notAfter - notBefore) / 12, or 7 days if notBefore is not defined.
+The scheduler will then sleep and wakeup after 12 hours.
+It is possible to start manually a renewal task with "acme renew'.
+See also "acme status" in the management guide.
+
+The following keywords are usable in the ACME section:
+
+account-key <filename>
+  Configure the path to the account key. The key need to be generated before
+  launching HAProxy. If no account keyword is used, the acme section will try
+  to load a filename using the section name "<name>.account.key". If the file
+  doesn't exist, HAProxy will generate one, using the parameters from the acme
+  section.
+
+  You can also generate manually an RSA private key with openssl:
+
+    openssl genrsa -out account.key 2048
+
+  Or an ecdsa one:
+
+    openssl ecparam -name secp384r1 -genkey -noout -out account.key
+
+bits <number>
+  Configure the number of bits to generate an RSA certificate. Default to 2048.
+  Setting a too high value can trigger a warning if your machine is not
+  powerful enough. (This can be configured with "warn-blocked-traffic-after"
+  but blocking the traffic too long could trigger the watchdog.)
+
+challenge <string>
+  Takes a challenge type as parameter, this must be HTTP-01 or DNS-01. When not
+  used the default is HTTP-01.
+
+contact <string>
+  The contact email that will be associated to the account key in the CA.
+
+curves <string>
+  When using the ECDSA keytype, configure the curves. The default is P-384.
+
+directory <string>
+  This keyword configures the directory URL for the CA used by this acme
+  section. This keyword is mandatory as there is no default URL.
+
+  Example:
+    directory https://acme-staging-v02.api.letsencrypt.org/directory
+
+keytype <string>
+  Configure the type of key that will be generated. Value can be either "RSA"
+  or "ECDSA". You can also configure the "curves" for ECDSA and the number of
+  "bits" for RSA. By default EC384 keys are generated.
+
+map <map>
+  Configure the map which will be used to store token (key) and thumbprint
+  (value), which is useful to reply to a challenge when there are multiple
+  account used. The acme task will add entries before validating the challenge
+  and will remove the entries at the end of the task.
+
+Example:
+
+  global
+      expose-experimental-directives
+      httpclient.resolvers.prefer ipv4
+
+  frontend in
+      bind *:80
+      bind *:443 ssl
+      http-request return status 200 content-type text/plain lf-string "%[path,field(-1,/)].%[path,field(-1,/),map(virt@acme)]\n" if { path_beg '/.well-known/acme-challenge/' }
+      ssl-f-use crt "foo.example.com.pem.rsa"   acme LE1 domains "foo.example.com.pem,bar.example.com"
+      ssl-f-use crt "foo.example.com.pem.ecdsa" acme LE2 domains "foo.example.com.pem,bar.example.com"
+
+  acme LE1
+      directory https://acme-staging-v02.api.letsencrypt.org/directory
+      account-key /etc/haproxy/letsencrypt.account.key
+      contact john.doe@example.com
+      challenge HTTP-01
+      keytype RSA
+      bits 2048
+      map virt@acme
+
+  acme LE2
+      directory https://acme-staging-v02.api.letsencrypt.org/directory
+      account-key /etc/haproxy/letsencrypt.account.key
+      contact john.doe@example.com
+      challenge HTTP-01
+      keytype ECDSA
+      curves P-384
+      map virt@acme
+
+12.9. Programs (deprecated)
+---------------------------
+
+This section is deprecated and should disappear with HAProxy 3.3. The section
+could be replaced easily by separated process managers. Systemd unit files or
+sysvinit scripts could replace this section as they are more reliable. In docker
+environments, some alternatives can also be found such as s6 or supervisord.
+
+In master-worker mode, it is possible to launch external binaries with the
+master, these processes are called programs. These programs are launched and
+managed the same way as the workers.
+
+Since version 3.1, the program section has a slightly different behavior, the
+section is parsed and the program is started from the master, but the rest of
+the configuration is loaded in the worker. This mean the program configuration
+is completely separated from the worker configuration, and a program could be
+reexecuted even if the worker configuration is wrong upon a reload.
+
+During a reload of HAProxy, those processes are dealing with the same
+sequence as a worker:
+
+  - the master is re-executed
+  - the master sends a SIGUSR1 signal to the program
+  - if "option start-on-reload" is not disabled, the master launches a new
+    instance of the program
+
+During a stop, or restart, a SIGTERM is sent to the programs.
+
+program <name>
+  This is a new program section, this section will create an instance <name>
+  which is visible in "show proc" on the master CLI. (See "9.4. Master CLI" in
+  the management guide).
+
+command <command> [arguments*]
+  Define the command to start with optional arguments. The command is looked
+  up in the current PATH if it does not include an absolute path. This is a
+  mandatory option of the program section. Arguments containing spaces must
+  be enclosed in quotes or double quotes or be prefixed by a backslash.
+
+user <user name>
+  Changes the executed command user ID to the <user name> from /etc/passwd.
+  See also "group".
+
+group <group name>
+  Changes the executed command group ID to the <group name> from /etc/group.
+  See also "user".
+
+option start-on-reload
+no option start-on-reload
+  Start (or not) a new instance of the program upon a reload of the master.
+  The default is to start a new instance. This option may only be used in a
+  program section.
+
+
 /*
  * Local variables:
  *  fill-column: 79