Configuration Manual
-version 3.1-dev13-8
+version 3.1-dev13-67
2024/11/15
@@ -5969,7 +5977,7 @@
2.9.<
- tune.quic.frontend.glitches-threshold
- tune.quic.frontend.max-idle-timeout
- tune.quic.frontend.max-streams-bidi
- - tune.quic.frontend.max-window-size
+ - tune.quic.frontend.default-max-window-size
- tune.quic.max-frame-loss
- tune.quic.reorder-ratio
- tune.quic.retry-threshold
@@ -9100,7 +9108,7 @@ 3.2.<
requests.
The default value is 100.
-Sets the default maximum window size for the congestion controller of a
+
Sets the default maximum window size for the congestion controller of a
single QUIC connection. The value must be written as an integer with an
optional suffix 'k', 'm' or 'g'. It must be between 10k and 4g.
@@ -11737,7 +11745,7 @@ 4.2.<
Arguments :<code> is the HTTP status code. Currently, HAProxy is capable of
generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410,
- 413, 425, 429, 500, 501, 502, 503, and 504.
+ 413, 414, 425, 429, 431, 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
@@ -11788,8 +11796,8 @@ 4.2.<
<code> is a HTTP status code. Several status code may be listed.
Currently, HAProxy is capable of generating codes 200, 400, 401,
- 403, 404, 405, 407, 408, 410, 413, 425, 429, 500, 501, 502, 503,
- and 504.
+ 403, 404, 405, 407, 408, 410, 413, 414, 425, 429, 431, 500, 501,
+ 502, 503, and 504.
Errors defined in the http-errors section with the name <name> are imported
in the current proxy. If no status code is specified, all error files of the
@@ -11815,7 +11823,7 @@ 4.2.<
Arguments :<code> is the HTTP status code. Currently, HAProxy is capable of
generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410,
- 413, 425, 429, 500, 501, 502, 503, and 504.
+ 413, 414, 425, 429, 431, 500, 501, 502, 503, and 504.
<url> it is the exact contents of the "Location" header. It may contain
either a relative URI to an error page hosted on the same site,
@@ -11847,7 +11855,7 @@ 4.2.<
Arguments :<code> is the HTTP status code. Currently, HAProxy is capable of
generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410,
- 413, 425, 429, 500, 501, 502, 503, and 504.
+ 413, 414, 425, 429, 431, 500, 501, 502, 503, and 504.
<url> it is the exact contents of the "Location" header. It may contain
either a relative URI to an error page hosted on the same site,
@@ -12735,8 +12743,8 @@ 4.2.<
Arguments :status <code> is the HTTP status code. It must be specified.
Currently, HAProxy is capable of generating codes
- 200, 400, 401, 403, 404, 405, 407, 408, 410, 413, 425,
- 429, 500, 501, 502, 503, and 504.
+ 200, 400, 401, 403, 404, 405, 407, 408, 410, 413,
+ 414, 425, 429, 431, 500, 501, 502, 503, and 504.
content-type <type> is the response content type, for instance
"text/plain". This parameter is ignored and should be
@@ -15906,13 +15914,26 @@ 4.2.<
that for a browser, a sole cookie name without an equal sign is
different from a cookie with an equal sign.
+ - "set-cookie-fmt <fmt>"
+ It is equivaliant to the option above, except the "Set-Cookie" header
+ will be filled with the result of the log-format string <fmt>
+ evaluation. Be carefull to respect the "NAME[=value]" format because no
+ special check are performed during the configuration parsing.
+
- "clear-cookie NAME[=]"
A "Set-Cookie" header will be added with NAME (and optionally "="), but
with the "Max-Age" attribute set to zero. This will tell the browser to
delete this cookie. It is useful for instance on logout pages. It is
important to note that clearing the cookie "NAME" will not remove a
cookie set with "NAME=value". You have to clear the cookie "NAME=" for
- that, because the browser makes the difference.
+ that, because the browser makes the difference.
+
+ - "keep-query"
+ When this keyword is used in a location-based redirection, then the
+ query-string of the original URI, if any, will be appended to the
+ location. If no query-string is found, nothing is added. If the
+ location already contains a query-string, the original one will be
+ appended with the '&' delimiter.
Example:
@@ -19770,21 +19791,22 @@ 4.4.<
* 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.
+ 414, 425, 429, 431, 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.
+ by HAProxy (200, 400, 403, 404, 405, 408, 410, 413, 414, 425, 429, 431,
+ 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.
+ 408, 410, 413, 414, 425, 429, 431, 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
@@ -21104,13 +21126,28 @@ 5.1.<
protocol for all connections instantiated from this listening socket. For
instance, it is possible to force the http/2 on clear TCP by specifying "proto
h2" on the bind line.
-This is a QUIC specific setting to select the congestion control algorithm
+
This is a QUIC specific setting to select the congestion control algorithm
for any connection attempts to the configured QUIC listeners. They are similar
-to those used by TCP. An optional value in bytes may be used to specify the
-maximum window size. It must be greater than 10k and smaller than 4g.
+to those used by TCP.
Default value: cubic
-Default window value: "tune.quic.frontend.max-window-size"
+
+It is possible to active pacing if the algorithm is compatible. This is done
+by using the suffix "-pacing" after the algorithm name. Pacing purpose is to
+smooth emission of data without burst to reduce network loss. In some
+scenario, it can significantly improve network throughput. However, it can
+also increase CPU usage if haproxy is forced to wait too long between each
+emission. Pacing support is still experimental, as such it requires
+"expose-experimental-directives".
+
+For further customization, a list of parameters can be specified after the
+algorithm token. It must be written between parenthesis, separated by a comma
+operator. Each argument is optional and can be empty if needed. Here is the
+mandatory order of each parameters :
+- maximum window size in bytes. It must be greater than 10k and smaller than
+ 4g. By default "tune.quic.frontend.default-max-window-size" value is used.
+- count of datagrams to emit in a burst if pacing is activated. It must be
+ between the default value of 1 and 1024.
Example:
@@ -21118,6 +21155,8 @@ 5.1.<
quic-cc-algo newreno
# cubic congestion control algorithm with one megabytes as window
quic-cc-algo cubic(1m)
+# cubic with pacing on top of it, with burst limited to 12 datagrams
+quic-cc-algo cubic-pacing(,12)
A special value "nocc" may be used to force a fixed congestion window always
set at the maximum size. It is reserved for debugging scenarios to remove any
@@ -21377,7 +21416,22 @@ 5.2.<
Values in this format will set the weight proportional to the initial
weight of a server as configured when HAProxy starts. Note that a zero
weight is reported on the stats page as "DRAIN" since it has the same
- effect on the server (it's removed from the LB farm).
+ effect on the server (it's removed from the LB farm). It is the legacy way
+ to set the weight of a server. Setting it with the "weight:" prefix is
+ preferred.
+
+- The string "weight:" following by an positive interger or a positive
+ interger percentage, with no space. If the value ends with the '%' sign,
+ then the new weight will be proportional to the initially weight of the
+ server. Otherwise, the value is considered as an absolute weight and must
+ be between 0 and 256. Servers which are part of a farm running a static
+ load-balancing algorithm have stricter limitations because the weight
+ cannot change once set. Thus for these servers, the only accepted values
+ are 0 and 100% (or 0 and the initial weight). Changes take effect
+ immediately, though certain LB algorithms require a certain amount of
+ requests to consider changes. Note that a zero weight is reported on the
+ stats page as "DRAIN" since it has the same effect on the server (it's
+ removed from the LB farm).
- The string "maxconn:" followed by an integer (no space between). Values
in this format will set the maxconn of a server. The maximum number of
@@ -25280,6 +25334,7 @@ txn.sess_term_state string
uuid([<version>]) string var(<var-name>[,<default>]) undefined wait_end boolean waiting_entity string Detailed list:
act_conn : integerReturns the total number of active concurrent connections on the process.
@@ -25688,7 +25743,30 @@ section 2.8 about
variables for details.
-
waiting_entity : stringThis returns the identity of the entity that was waiting to continue its
+
wait_end : booleanThis fetch either returns true when the inspection period is over, or does
+not fetch. It is only used in ACLs, in conjunction with content analysis to
+avoid returning a wrong verdict early. It may also be used to delay some
+actions, such as a delayed reject for some special addresses. Since it either
+stops the rules evaluation or immediately returns true, it is recommended to
+use this acl as the last one in a rule. Please note that the default ACL
+"WAIT_END" is always usable without prior declaration. This test was designed
+to be used with TCP request content inspection.
+
+Examples :
+
+# delay every incoming request by 2 seconds
+tcp-request inspect-delay 2s
+tcp-request content accept if WAIT_END
+
+# don't immediately tell bad guys they are rejected
+tcp-request inspect-delay 10s
+acl goodguys src 10.0.0.0/24
+acl badguys src 10.0.1.0/24
+tcp-request content accept if goodguys
+tcp-request content reject if badguys WAIT_END
+tcp-request content reject
+
+waiting_entity : stringThis returns the identity of the entity that was waiting to continue its
processing when an error or a timeout was encountered. It may be the a rule
or a filter for instance. However, this list is not exhaustive and the format
of all possible entities is not forcefully documented.
@@ -26773,6 +26851,14 @@ Detailed list:
Returns values for the properties requested as a string, where values are
@@ -26896,10 +26982,67 @@
-
ssl_bc : booleanReturns true when the back connection was made via an SSL/TLS transport
+
bs.aborted : booleanReturns true is an abort was received from the server for the current
+stream. Otherwise false is returned.
+
This function is meant to be used by developers during certain complex
+troubleshooting sessions. It extracts some internal states from the lower
+layers of the backend stream and connection, and arranges them as a string,
+generally in the form of a series of "name=value" delimited with spaces. The
+<bitmap> optional argument indicates what layer(s) to extract information
+from, and is an arithmetic OR (or a sum) of the following values:
+ - socket layer: 16
+ - connection layer: 8
+ - transport layer (e.g. SSL): 4
+ - mux connection: 2
+ - mux stream: 1
+
+These values might change across versions. The default value of zero is
+special and enables all layers. Please do not rely on the output of this
+function for long-term production monitoring. It is meant to evolve even
+within a stable branch, as the needs for increased details arise. One use
+typical use case is to concatenate these information at the very end of a
+log-format, along with fs.debug_str(). Example:
+
+ log-format "$HAPROXY_HTTP_LOG_FMT fs=<%[fs.debug_str]> bs=<%[bs.debug_str]>"
+
bs.id : integerReturns the multiplexer's stream ID on the server side. It is the
+multiplexer's responsibility to return the appropriate information.
+
bs.rst_code : integerReturns the reset code received from the server for the current stream. The
+code of the H2 RST_STREAM frame or the QUIC STOP_SENDING frame received from
+the server is returned. The sample fetch fails if no abort was received or if
+the server stream is not an H2/QUIC stream.
+
ssl_bc : booleanReturns true when the back connection was made via an SSL/TLS transport
layer and is locally deciphered. This means the outgoing connection was made
to a server with the "ssl" option. It can be used in a tcp-check or an
http-check ruleset.
+fs.aborted : booleanReturns true is an abort was received from the client for the current
+stream. Otherwise false is returned.
+
This function is meant to be used by developers during certain complex
+troubleshooting sessions. It extracts some internal states from the lower
+layers of the frontend stream and connection, and arranges them as a string,
+generally in the form of a series of "name=value" delimited with spaces. The
+<bitmap> optional argument indicates what layer(s) to extract information
+from, and is an arithmetic OR (or a sum) of the following values:
+ - socket layer: 16
+ - connection layer: 8
+ - transport layer (e.g. SSL): 4
+ - mux connection: 2
+ - mux stream: 1
+
+These values might change across versions. The default value of zero is
+special and enables all layers. Please do not rely on the output of this
+function for long-term production monitoring. It is meant to evolve even
+within a stable branch, as the needs for increased details arise. One use
+typical use case is to concatenate these information at the very end of a
+log-format, along with bs.debug_str(). Example:
+
+ log-format "$HAPROXY_HTTP_LOG_FMT fs=<%[fs.debug_str]> bs=<%[bs.debug_str]>"
+
fs.id : integerReturns the multiplexer's stream ID on the client side. It is the
+multiplexer's responsibility to return the appropriate information. For
+instance, on a raw TCP, 0 is always returned because there is no stream.
+
fs.rst_code : integerReturns the reset code received from the client for the current stream. The
+code of the H2 RST_STREAM frame or the QUIC STOP_SENDING frame received from
+the client is returned. The sample fetch fails if no abort was received or
+if the client stream is not an H2/QUIC stream.
ssl_bc_alg_keysize : integerReturns the symmetric cipher key size supported in bits when the outgoing
connection was made over an SSL/TLS transport layer. It can be used in a
tcp-check or an http-check ruleset.
@@ -27549,16 +27692,8 @@
keyword output type bs.aborted boolean bs.debug_str([<bitmap>]) string bs.id integer bs.rst_code integer distcc_body(<token>[,<occ>]) binary distcc_param(<token>[,<occ>]) integer fs.aborted boolean fs.debug_str([<bitmap>]) string fs.id integer fs.rst_code integer payload(<offset>,<length>) binary payload_lv(<offset1>,<length>[,<offset2>]) binary req.len integer res.payload_lv(<offset1>,<length>[,<offset2>]) binary
res.ssl_hello_type integer rep_ssl_hello_type integer wait_end boolean
Detailed list:
-
-bs.aborted: boolean
- Returns true is an abort was received from the server for the current
- stream. Otherwise false is returned.
-
This function is meant to be used by developers during certain complex
-troubleshooting sessions. It extracts some internal states from the lower
-layers of the backend stream and connection, and arranges them as a string,
-generally in the form of a series of "name=value" delimited with spaces. The
-<bitmap> optional argument indicates what layer(s) to extract information
-from, and is an arithmetic OR (or a sum) of the following values:
- - socket layer: 16
- - connection layer: 8
- - transport layer (e.g. SSL): 4
- - mux connection: 2
- - mux stream: 1
-
-These values might change across versions. The default value of zero is
-special and enables all layers. Please do not rely on the output of this
-function for long-term production monitoring. It is meant to evolve even
-within a stable branch, as the needs for increased details arise. One use
-typical use case is to concatenate these information at the very end of a
-log-format, along with fs.debug_str(). Example:
-
- log-format "$HAPROXY_HTTP_LOG_FMT fs=<%[fs.debug_str]> bs=<%[bs.debug_str]>"
-
bs.id : integer Returns the multiplexer's stream ID on the server side. It is the
- multiplexer's responsibility to return the appropriate information.
-
-bs.rst_code: integer
- Returns the reset code received from the server for the current stream. The
- code of the H2 RST_STREAM frame or the QUIC STOP_SENDING frame received from
- the server is returned. The sample fetch fails if no abort was received or if
- the server stream is not an H2/QUIC stream.
Parses a distcc message and returns the body associated to occurrence #<occ>
of the token <token>. Occurrences start at 1, and when unspecified, any may
match though in practice only the first one is checked for now. This can be
@@ -27643,39 +27745,7 @@ # send large files to the big farm
use_backend big_farm if { distcc_param(DOTI) gt 1000000 }
-
fs.aborted: boolean
- Returns true is an abort was received from the client for the current
- stream. Otherwise false is returned.
-
This function is meant to be used by developers during certain complex
-troubleshooting sessions. It extracts some internal states from the lower
-layers of the frontend stream and connection, and arranges them as a string,
-generally in the form of a series of "name=value" delimited with spaces. The
-<bitmap> optional argument indicates what layer(s) to extract information
-from, and is an arithmetic OR (or a sum) of the following values:
- - socket layer: 16
- - connection layer: 8
- - transport layer (e.g. SSL): 4
- - mux connection: 2
- - mux stream: 1
-
-These values might change across versions. The default value of zero is
-special and enables all layers. Please do not rely on the output of this
-function for long-term production monitoring. It is meant to evolve even
-within a stable branch, as the needs for increased details arise. One use
-typical use case is to concatenate these information at the very end of a
-log-format, along with bs.debug_str(). Example:
-
- log-format "$HAPROXY_HTTP_LOG_FMT fs=<%[fs.debug_str]> bs=<%[bs.debug_str]>"
-
fs.id : integer Returns the multiplexer's stream ID on the client side. It is the
- multiplexer's responsibility to return the appropriate information. For
- instance, on a raw TCP, 0 is always returned because there is no stream.
-
-fs.rst_code: integer
- Returns the reset code received from the client for the current stream. The
- code of the H2 RST_STREAM frame or the QUIC STOP_SENDING frame received from
- the client is returned. The sample fetch fails if no abort was received or
- if the client stream is not an H2/QUIC stream.
-
This is an alias for "req.payload" when used in the context of a request (e.g.
+
Sets the default maximum window size for the congestion controller of a +
Sets the default maximum window size for the congestion controller of a single QUIC connection. The value must be written as an integer with an optional suffix 'k', 'm' or 'g'. It must be between 10k and 4g. @@ -11737,7 +11745,7 @@4.2.<
Arguments :<code> is the HTTP status code. Currently, HAProxy is capable of generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410, - 413, 425, 429, 500, 501, 502, 503, and 504. + 413, 414, 425, 429, 431, 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 @@ -11788,8 +11796,8 @@+ 403, 404, 405, 407, 408, 410, 413, 414, 425, 429, 431, 500, 501, + 502, 503, and 504.4.2.< <code> is a HTTP status code. Several status code may be listed. Currently, HAProxy is capable of generating codes 200, 400, 401, - 403, 404, 405, 407, 408, 410, 413, 425, 429, 500, 501, 502, 503, - and 504.
Errors defined in the http-errors section with the name <name> are imported in the current proxy. If no status code is specified, all error files of the @@ -11815,7 +11823,7 @@4.2.<
Arguments :<code> is the HTTP status code. Currently, HAProxy is capable of generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410, - 413, 425, 429, 500, 501, 502, 503, and 504. + 413, 414, 425, 429, 431, 500, 501, 502, 503, and 504. <url> it is the exact contents of the "Location" header. It may contain either a relative URI to an error page hosted on the same site, @@ -11847,7 +11855,7 @@4.2.<
Arguments :<code> is the HTTP status code. Currently, HAProxy is capable of generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410, - 413, 425, 429, 500, 501, 502, 503, and 504. + 413, 414, 425, 429, 431, 500, 501, 502, 503, and 504. <url> it is the exact contents of the "Location" header. It may contain either a relative URI to an error page hosted on the same site, @@ -12735,8 +12743,8 @@4.2.<
Arguments :status <code> is the HTTP status code. It must be specified. Currently, HAProxy is capable of generating codes - 200, 400, 401, 403, 404, 405, 407, 408, 410, 413, 425, - 429, 500, 501, 502, 503, and 504. + 200, 400, 401, 403, 404, 405, 407, 408, 410, 413, + 414, 425, 429, 431, 500, 501, 502, 503, and 504. content-type <type> is the response content type, for instance "text/plain". This parameter is ignored and should be @@ -15906,13 +15914,26 @@+ that, because the browser makes the difference. + + - "keep-query" + When this keyword is used in a location-based redirection, then the + query-string of the original URI, if any, will be appended to the + location. If no query-string is found, nothing is added. If the + location already contains a query-string, the original one will be + appended with the '&' delimiter.4.2.< that for a browser, a sole cookie name without an equal sign is different from a cookie with an equal sign. + - "set-cookie-fmt <fmt>" + It is equivaliant to the option above, except the "Set-Cookie" header + will be filled with the result of the log-format string <fmt> + evaluation. Be carefull to respect the "NAME[=value]" format because no + special check are performed during the configuration parsing. + - "clear-cookie NAME[=]" A "Set-Cookie" header will be added with NAME (and optionally "="), but with the "Max-Age" attribute set to zero. This will tell the browser to delete this cookie. It is useful for instance on logout pages. It is important to note that clearing the cookie "NAME" will not remove a cookie set with "NAME=value". You have to clear the cookie "NAME=" for - that, because the browser makes the difference.
Example: @@ -19770,21 +19791,22 @@4.4.< * 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. + 414, 425, 429, 431, 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. + by HAProxy (200, 400, 403, 404, 405, 408, 410, 413, 414, 425, 429, 431, + 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. + 408, 410, 413, 414, 425, 429, 431, 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 @@ -21104,13 +21126,28 @@
5.1.< protocol for all connections instantiated from this listening socket. For instance, it is possible to force the http/2 on clear TCP by specifying "proto h2" on the bind line. -
This is a QUIC specific setting to select the congestion control algorithm +This is a QUIC specific setting to select the congestion control algorithm for any connection attempts to the configured QUIC listeners. They are similar -to those used by TCP. An optional value in bytes may be used to specify the -maximum window size. It must be greater than 10k and smaller than 4g. +to those used by TCP. Default value: cubic -Default window value: "tune.quic.frontend.max-window-size" + +It is possible to active pacing if the algorithm is compatible. This is done +by using the suffix "-pacing" after the algorithm name. Pacing purpose is to +smooth emission of data without burst to reduce network loss. In some +scenario, it can significantly improve network throughput. However, it can +also increase CPU usage if haproxy is forced to wait too long between each +emission. Pacing support is still experimental, as such it requires +"expose-experimental-directives". + +For further customization, a list of parameters can be specified after the +algorithm token. It must be written between parenthesis, separated by a comma +operator. Each argument is optional and can be empty if needed. Here is the +mandatory order of each parameters : +- maximum window size in bytes. It must be greater than 10k and smaller than + 4g. By default "tune.quic.frontend.default-max-window-size" value is used. +- count of datagrams to emit in a burst if pacing is activated. It must be + between the default value of 1 and 1024.Example:@@ -21118,6 +21155,8 @@5.1.< quic-cc-algo newreno # cubic congestion control algorithm with one megabytes as window quic-cc-algo cubic(1m) +# cubic with pacing on top of it, with burst limited to 12 datagrams +quic-cc-algo cubic-pacing(,12)
A special value "nocc" may be used to force a fixed congestion window always set at the maximum size. It is reserved for debugging scenarios to remove any @@ -21377,7 +21416,22 @@5.2.< Values in this format will set the weight proportional to the initial weight of a server as configured when HAProxy starts. Note that a zero weight is reported on the stats page as "DRAIN" since it has the same - effect on the server (it's removed from the LB farm). + effect on the server (it's removed from the LB farm). It is the legacy way + to set the weight of a server. Setting it with the "weight:" prefix is + preferred. + +- The string "weight:" following by an positive interger or a positive + interger percentage, with no space. If the value ends with the '%' sign, + then the new weight will be proportional to the initially weight of the + server. Otherwise, the value is considered as an absolute weight and must + be between 0 and 256. Servers which are part of a farm running a static + load-balancing algorithm have stricter limitations because the weight + cannot change once set. Thus for these servers, the only accepted values + are 0 and 100% (or 0 and the initial weight). Changes take effect + immediately, though certain LB algorithms require a certain amount of + requests to consider changes. Note that a zero weight is reported on the + stats page as "DRAIN" since it has the same effect on the server (it's + removed from the LB farm). - The string "maxconn:" followed by an integer (no space between). Values in this format will set the maxconn of a server. The maximum number of @@ -25280,6 +25334,7 @@
txn.sess_term_state string uuid([<version>]) string + var(<var-name>[,<default>]) undefined wait_end boolean waiting_entity string Detailed list:act_conn : integerReturns the total number of active concurrent connections on the process. @@ -25688,7 +25743,30 @@section 2.8 about variables for details. -
waiting_entity : stringThis returns the identity of the entity that was waiting to continue its +wait_end : booleanThis fetch either returns true when the inspection period is over, or does +not fetch. It is only used in ACLs, in conjunction with content analysis to +avoid returning a wrong verdict early. It may also be used to delay some +actions, such as a delayed reject for some special addresses. Since it either +stops the rules evaluation or immediately returns true, it is recommended to +use this acl as the last one in a rule. Please note that the default ACL +"WAIT_END" is always usable without prior declaration. This test was designed +to be used with TCP request content inspection. ++Examples : +++# delay every incoming request by 2 seconds +tcp-request inspect-delay 2s +tcp-request content accept if WAIT_END + +# don't immediately tell bad guys they are rejected +tcp-request inspect-delay 10s +acl goodguys src 10.0.0.0/24 +acl badguys src 10.0.1.0/24 +tcp-request content accept if goodguys +tcp-request content reject if badguys WAIT_END +tcp-request content reject +waiting_entity : stringThis returns the identity of the entity that was waiting to continue its processing when an error or a timeout was encountered. It may be the a rule or a filter for instance. However, this list is not exhaustive and the format of all possible entities is not forcefully documented. @@ -26773,6 +26851,14 @@
Detailed list:Returns values for the properties requested as a string, where values are @@ -26896,10 +26982,67 @@-ssl_bc : booleanReturns true when the back connection was made via an SSL/TLS transport +bs.aborted : booleanReturns true is an abort was received from the server for the current +stream. Otherwise false is returned. +This function is meant to be used by developers during certain complex +troubleshooting sessions. It extracts some internal states from the lower +layers of the backend stream and connection, and arranges them as a string, +generally in the form of a series of "name=value" delimited with spaces. The +<bitmap> optional argument indicates what layer(s) to extract information +from, and is an arithmetic OR (or a sum) of the following values: + - socket layer: 16 + - connection layer: 8 + - transport layer (e.g. SSL): 4 + - mux connection: 2 + - mux stream: 1 + +These values might change across versions. The default value of zero is +special and enables all layers. Please do not rely on the output of this +function for long-term production monitoring. It is meant to evolve even +within a stable branch, as the needs for increased details arise. One use +typical use case is to concatenate these information at the very end of a +log-format, along with fs.debug_str(). Example: + + log-format "$HAPROXY_HTTP_LOG_FMT fs=<%[fs.debug_str]> bs=<%[bs.debug_str]>" +bs.id : integerReturns the multiplexer's stream ID on the server side. It is the +multiplexer's responsibility to return the appropriate information. +bs.rst_code : integerReturns the reset code received from the server for the current stream. The +code of the H2 RST_STREAM frame or the QUIC STOP_SENDING frame received from +the server is returned. The sample fetch fails if no abort was received or if +the server stream is not an H2/QUIC stream. +ssl_bc : booleanReturns true when the back connection was made via an SSL/TLS transport layer and is locally deciphered. This means the outgoing connection was made to a server with the "ssl" option. It can be used in a tcp-check or an http-check ruleset. +fs.aborted : booleanReturns true is an abort was received from the client for the current +stream. Otherwise false is returned. +This function is meant to be used by developers during certain complex +troubleshooting sessions. It extracts some internal states from the lower +layers of the frontend stream and connection, and arranges them as a string, +generally in the form of a series of "name=value" delimited with spaces. The +<bitmap> optional argument indicates what layer(s) to extract information +from, and is an arithmetic OR (or a sum) of the following values: + - socket layer: 16 + - connection layer: 8 + - transport layer (e.g. SSL): 4 + - mux connection: 2 + - mux stream: 1 + +These values might change across versions. The default value of zero is +special and enables all layers. Please do not rely on the output of this +function for long-term production monitoring. It is meant to evolve even +within a stable branch, as the needs for increased details arise. One use +typical use case is to concatenate these information at the very end of a +log-format, along with bs.debug_str(). Example: + + log-format "$HAPROXY_HTTP_LOG_FMT fs=<%[fs.debug_str]> bs=<%[bs.debug_str]>" +fs.id : integerReturns the multiplexer's stream ID on the client side. It is the +multiplexer's responsibility to return the appropriate information. For +instance, on a raw TCP, 0 is always returned because there is no stream. +fs.rst_code : integerReturns the reset code received from the client for the current stream. The +code of the H2 RST_STREAM frame or the QUIC STOP_SENDING frame received from +the client is returned. The sample fetch fails if no abort was received or +if the client stream is not an H2/QUIC stream.ssl_bc_alg_keysize : integerReturns the symmetric cipher key size supported in bits when the outgoing connection was made over an SSL/TLS transport layer. It can be used in a tcp-check or an http-check ruleset. @@ -27549,16 +27692,8 @@
- keyword output type - bs.aborted boolean - bs.debug_str([<bitmap>]) string - bs.id integer bs.rst_code integer distcc_body(<token>[,<occ>]) binary - distcc_param(<token>[,<occ>]) integer - fs.aborted boolean - fs.debug_str([<bitmap>]) string - fs.id integer fs.rst_code integer payload(<offset>,<length>) binary payload_lv(<offset1>,<length>[,<offset2>]) binary @@ -27585,40 +27720,7 @@ req.len integer
res.payload_lv(<offset1>,<length>[,<offset2>]) binary res.ssl_hello_type integer - rep_ssl_hello_type integer wait_end boolean Detailed list: - -bs.aborted: boolean - Returns true is an abort was received from the server for the current - stream. Otherwise false is returned. -This function is meant to be used by developers during certain complex -troubleshooting sessions. It extracts some internal states from the lower -layers of the backend stream and connection, and arranges them as a string, -generally in the form of a series of "name=value" delimited with spaces. The -<bitmap> optional argument indicates what layer(s) to extract information -from, and is an arithmetic OR (or a sum) of the following values: - - socket layer: 16 - - connection layer: 8 - - transport layer (e.g. SSL): 4 - - mux connection: 2 - - mux stream: 1 - -These values might change across versions. The default value of zero is -special and enables all layers. Please do not rely on the output of this -function for long-term production monitoring. It is meant to evolve even -within a stable branch, as the needs for increased details arise. One use -typical use case is to concatenate these information at the very end of a -log-format, along with fs.debug_str(). Example: - - log-format "$HAPROXY_HTTP_LOG_FMT fs=<%[fs.debug_str]> bs=<%[bs.debug_str]>" -bs.id : integerReturns the multiplexer's stream ID on the server side. It is the - multiplexer's responsibility to return the appropriate information. - -bs.rst_code: integer - Returns the reset code received from the server for the current stream. The - code of the H2 RST_STREAM frame or the QUIC STOP_SENDING frame received from - the server is returned. The sample fetch fails if no abort was received or if - the server stream is not an H2/QUIC stream.Parses a distcc message and returns the body associated to occurrence #<occ> of the token <token>. Occurrences start at 1, and when unspecified, any may match though in practice only the first one is checked for now. This can be @@ -27643,39 +27745,7 @@-# send large files to the big farm use_backend big_farm if { distcc_param(DOTI) gt 1000000 }
fs.aborted: boolean - Returns true is an abort was received from the client for the current - stream. Otherwise false is returned. -This function is meant to be used by developers during certain complex -troubleshooting sessions. It extracts some internal states from the lower -layers of the frontend stream and connection, and arranges them as a string, -generally in the form of a series of "name=value" delimited with spaces. The -<bitmap> optional argument indicates what layer(s) to extract information -from, and is an arithmetic OR (or a sum) of the following values: - - socket layer: 16 - - connection layer: 8 - - transport layer (e.g. SSL): 4 - - mux connection: 2 - - mux stream: 1 - -These values might change across versions. The default value of zero is -special and enables all layers. Please do not rely on the output of this -function for long-term production monitoring. It is meant to evolve even -within a stable branch, as the needs for increased details arise. One use -typical use case is to concatenate these information at the very end of a -log-format, along with bs.debug_str(). Example: - - log-format "$HAPROXY_HTTP_LOG_FMT fs=<%[fs.debug_str]> bs=<%[bs.debug_str]>" -fs.id : integerReturns the multiplexer's stream ID on the client side. It is the - multiplexer's responsibility to return the appropriate information. For - instance, on a raw TCP, 0 is always returned because there is no stream. - -fs.rst_code: integer - Returns the reset code received from the client for the current stream. The - code of the H2 RST_STREAM frame or the QUIC STOP_SENDING frame received from - the client is returned. The sample fetch fails if no abort was received or - if the client stream is not an H2/QUIC stream. -This is an alias for "req.payload" when used in the context of a request (e.g. +