[DOC] rearrange the configuration manual and add a summary
Several people have asked for a summary in order to ease finding
of sections in the configuration manual. It was the opportunity to
tidy it up a bit and rearrange some sections.
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 87bbc85..3545b29 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -10,12 +10,314 @@
This document covers the configuration language as implemented in the version
specified above. It does not provide any hint, example or advice. For such
documentation, please refer to the Reference Manual or the Architecture Manual.
+The summary below is meant to help you search sections by name and navigate
+through the document.
-Note to documentation contributors : this document is formated with 80 columns
-per line, with even number of spaces for indentation and without tabs. Please
-follow these rules strictly so that it remains easily printable everywhere. If
-a line needs to be printed verbatim and does not fit, please end each line with
-a backslash ('\') and continue on next line.
+Note to documentation contributors :
+ This document is formated with 80 columns per line, with even number of
+ spaces for indentation and without tabs. Please follow these rules strictly
+ so that it remains easily printable everywhere. If a line needs to be
+ printed verbatim and does not fit, please end each line with a backslash
+ ('\') and continue on next line. If you add sections, please update the
+ summary below for easier searching.
+
+
+Summary
+-------
+
+1. Quick reminder about HTTP
+1.1. The HTTP transaction model
+1.2. HTTP request
+1.2.1. The Request line
+1.2.2. The request headers
+1.3. HTTP response
+1.3.1. The Response line
+1.3.2. The response headers
+
+2. Configuring HAProxy
+2.1. Configuration file format
+2.2. Time format
+
+3. Global parameters
+3.1. Process management and security
+3.2. Performance tuning
+3.3. Debugging
+
+4. Proxies
+4.1. Proxy keywords matrix
+4.2. Alphabetically sorted keywords reference
+
+5. Server options
+
+6. HTTP header manipulation
+
+7. Using ACLs
+7.1. Matching integers
+7.2. Matching strings
+7.3. Matching regular expressions (regexes)
+7.4. Matching IPv4 addresses
+7.5. Available matching criteria
+7.5.1. Matching at Layer 4 and below
+7.5.2. Matching contents at Layer 4
+7.5.3. Matching at Layer 7
+7.6. Pre-defined ACLs
+7.7. Using ACLs to form conditions
+
+8. Logging
+8.1. Log levels
+8.2. Log formats
+8.2.1. Default log format
+8.2.2. TCP log format
+8.2.3. HTTP log format
+8.3. Advanced logging options
+8.3.1. Disabling logging of external tests
+8.3.2. Logging before waiting for the session to terminate
+8.3.3. Raising log level upon errors
+8.3.4. Disabling logging of successful connections
+8.4. Timing events
+8.5. Session state at disconnection
+8.6. Non-printable characters
+8.7. Capturing HTTP cookies
+8.8. Capturing HTTP headers
+8.9. Examples of logs
+
+9. Statistics and monitoring
+9.1. CSV format
+9.2. Unix Socket commands
+
+
+1. Quick reminder about HTTP
+----------------------------
+
+When haproxy is running in HTTP mode, both the request and the response are
+fully analyzed and indexed, thus it becomes possible to build matching criteria
+on almost anything found in the contents.
+
+However, it is important to understand how HTTP requests and responses are
+formed, and how HAProxy decomposes them. It will then become easier to write
+correct rules and to debug existing configurations.
+
+
+1.1. The HTTP transaction model
+-------------------------------
+
+The HTTP protocol is transaction-driven. This means that each request will lead
+to one and only one response. Traditionnally, a TCP connection is established
+from the client to the server, a request is sent by the client on the
+connection, the server responds and the connection is closed. A new request
+will involve a new connection :
+
+ [CON1] [REQ1] ... [RESP1] [CLO1] [CON2] [REQ2] ... [RESP2] [CLO2] ...
+
+In this mode, called the "HTTP close" mode, there are as many connection
+establishments as there are HTTP transactions. Since the connection is closed
+by the server after the response, the client does not need to know the content
+length.
+
+Due to the transactional nature of the protocol, it was possible to improve it
+to avoid closing a connection between two subsequent transactions. In this mode
+however, it is mandatory that the server indicates the content length for each
+response so that the client does not wait indefinitely. For this, a special
+header is used: "Content-length". This mode is called the "keep-alive" mode :
+
+ [CON] [REQ1] ... [RESP1] [REQ2] ... [RESP2] [CLO] ...
+
+Its advantages are a reduced latency between transactions, and less processing
+power required on the server side. It is generally better than the close mode,
+but not always because the clients often limit their concurrent connections to
+a smaller value. HAProxy currently does not support the HTTP keep-alive mode,
+but knows how to transform it to the close mode.
+
+A last improvement in the communications is the pipelining mode. It still uses
+keep-alive, but the client does not wait for the first response to send the
+second request. This is useful for fetching large number of images composing a
+page :
+
+ [CON] [REQ1] [REQ2] ... [RESP1] [RESP2] [CLO] ...
+
+This can obviously have a tremendous benefit on performance because the network
+latency is eliminated between subsequent requests. Many HTTP agents do not
+correctly support pipelining since there is no way to associate a response with
+the corresponding request in HTTP. For this reason, it is mandatory for the
+server to reply in the exact same order as the requests were received.
+
+Right now, HAProxy only supports the first mode (HTTP close) if it needs to
+process the request. This means that for each request, there will be one TCP
+connection. If keep-alive or pipelining are required, HAProxy will still
+support them, but will only see the first request and the first response of
+each transaction. While this is generally problematic with regards to logs,
+content switching or filtering, it most often causes no problem for persistence
+with cookie insertion.
+
+
+1.2. HTTP request
+-----------------
+
+First, let's consider this HTTP request :
+
+ Line Contents
+ number
+ 1 GET /serv/login.php?lang=en&profile=2 HTTP/1.1
+ 2 Host: www.mydomain.com
+ 3 User-agent: my small browser
+ 4 Accept: image/jpeg, image/gif
+ 5 Accept: image/png
+
+
+1.2.1. The Request line
+-----------------------
+
+Line 1 is the "request line". It is always composed of 3 fields :
+
+ - a METHOD : GET
+ - a URI : /serv/login.php?lang=en&profile=2
+ - a version tag : HTTP/1.1
+
+All of them are delimited by what the standard calls LWS (linear white spaces),
+which are commonly spaces, but can also be tabs or line feeds/carriage returns
+followed by spaces/tabs. The method itself cannot contain any colon (':') and
+is limited to alphabetic letters. All those various combinations make it
+desirable that HAProxy performs the splitting itself rather than leaving it to
+the user to write a complex or inaccurate regular expression.
+
+The URI itself can have several forms :
+
+ - A "relative URI" :
+
+ /serv/login.php?lang=en&profile=2
+
+ It is a complete URL without the host part. This is generally what is
+ received by servers, reverse proxies and transparent proxies.
+
+ - An "absolute URI", also called a "URL" :
+
+ http://192.168.0.12:8080/serv/login.php?lang=en&profile=2
+
+ It is composed of a "scheme" (the protocol name followed by '://'), a host
+ name or address, optionally a colon (':') followed by a port number, then
+ a relative URI beginning at the first slash ('/') after the address part.
+ This is generally what proxies receive, but a server supporting HTTP/1.1
+ must accept this form too.
+
+ - a star ('*') : this form is only accepted in association with the OPTIONS
+ method and is not relayable. It is used to inquiry a next hop's
+ capabilities.
+
+ - an address:port combination : 192.168.0.12:80
+ This is used with the CONNECT method, which is used to establish TCP
+ tunnels through HTTP proxies, generally for HTTPS, but sometimes for
+ other protocols too.
+
+In a relative URI, two sub-parts are identified. The part before the question
+mark is called the "path". It is typically the relative path to static objects
+on the server. The part after the question mark is called the "query string".
+It is mostly used with GET requests sent to dynamic scripts and is very
+specific to the language, framework or application in use.
+
+
+1.2.2. The request headers
+--------------------------
+
+The headers start at the second line. They are composed of a name at the
+beginning of the line, immediately followed by a colon (':'). Traditionally,
+an LWS is added after the colon but that's not required. Then come the values.
+Multiple identical headers may be folded into one single line, delimiting the
+values with commas, provided that their order is respected. This is commonly
+encountered in the "Cookie:" field. A header may span over multiple lines if
+the subsequent lines begin with an LWS. In the example in 1.2, lines 4 and 5
+define a total of 3 values for the "Accept:" header.
+
+Contrary to a common mis-conception, header names are not case-sensitive, and
+their values are not either if they refer to other header names (such as the
+"Connection:" header).
+
+The end of the headers is indicated by the first empty line. People often say
+that it's a double line feed, which is not exact, even if a double line feed
+is one valid form of empty line.
+
+Fortunately, HAProxy takes care of all these complex combinations when indexing
+headers, checking values and counting them, so there is no reason to worry
+about the way they could be written, but it is important not to accuse an
+application of being buggy if it does unusual, valid things.
+
+Important note:
+ As suggested by RFC2616, HAProxy normalizes headers by replacing line breaks
+ in the middle of headers by LWS in order to join multi-line headers. This
+ is necessary for proper analysis and helps less capable HTTP parsers to work
+ correctly and not to be fooled by such complex constructs.
+
+
+1.3. HTTP response
+------------------
+
+An HTTP response looks very much like an HTTP request. Both are called HTTP
+messages. Let's consider this HTTP response :
+
+ Line Contents
+ number
+ 1 HTTP/1.1 200 OK
+ 2 Content-length: 350
+ 3 Content-Type: text/html
+
+
+1.3.1. The Response line
+------------------------
+
+Line 1 is the "response line". It is always composed of 3 fields :
+
+ - a version tag : HTTP/1.1
+ - a status code : 200
+ - a reason : OK
+
+The status code is always 3-digit. The first digit indicates a general status :
+ - 2xx = OK, content is following (eg: 200, 206)
+ - 3xx = OK, no content following (eg: 302, 304)
+ - 4xx = error caused by the client (eg: 401, 403, 404)
+ - 5xx = error caused by the server (eg: 500, 502, 503)
+
+Please refer to RFC2616 for the detailed meaning of all such codes. The
+"reason" field is just a hint, but is not parsed by clients. Anything can be
+found there, but it's a common practice to respect the well-established
+messages. It can be composed of one or multiple words, such as "OK", "Found",
+or "Authentication Required".
+
+Haproxy may emit the following status codes by itself :
+
+ Code When / reason
+ 200 access to stats page, and when replying to monitoring requests
+ 301 when performing a redirection, depending on the configured code
+ 302 when performing a redirection, depending on the configured code
+ 303 when performing a redirection, depending on the configured code
+ 400 for an invalid or too large request
+ 401 when an authentication is required to perform the action (when
+ accessing the stats page)
+ 403 when a request is forbidden by a "block" ACL or "reqdeny" filter
+ 408 when the request timeout strikes before the request is complete
+ 500 when haproxy encounters an unrecoverable internal error, such as a
+ memory allocation failure, which should never happen
+ 502 when the server returns an empty, invalid or incomplete response, or
+ when an "rspdeny" filter blocks the response.
+ 503 when no server was available to handle the request, or in response to
+ monitoring requests which match the "monitor fail" condition
+ 504 when the response timeout strikes before the server responds
+
+The error 4xx and 5xx codes above may be customized (see "errorloc" in section
+4.2).
+
+
+1.3.2. The response headers
+---------------------------
+
+Response headers work exactly like request headers, and as such, HAProxy uses
+the same parsing function for both. Please refer to paragraph 1.2.2 for more
+details.
+
+
+2. Configuring HAProxy
+----------------------
+
+2.1. Configuration file format
+------------------------------
HAProxy's configuration process involves 3 major sources of parameters :
@@ -30,6 +332,10 @@
preceeded by a backslash ('\') to be escaped. Backslashes also have to be
escaped by doubling them.
+
+2.2. Time format
+----------------
+
Some parameters involve values representating time, such as timeouts. These
values are generally expressed in milliseconds (unless explicitly stated
otherwise) but may be expressed in any other unit by suffixing the unit to the
@@ -44,7 +350,7 @@
- d : days. 1d = 24h = 1440m = 86400s = 86400000ms
-1. Global parameters
+3. Global parameters
--------------------
Parameters in the "global" section are process-wide and often OS-specific. They
@@ -83,7 +389,7 @@
- quiet
-1.1) Process management and security
+3.1. Process management and security
------------------------------------
chroot <jail dir>
@@ -191,7 +497,7 @@
See also "uid" and "group".
-1.2) Performance tuning
+3.2. Performance tuning
-----------------------
maxconn <number>
@@ -265,8 +571,8 @@
tends to trade latency for slightly increased bandwidth.
-1.3) Debugging
----------------
+3.3. Debugging
+--------------
debug
Enables debug mode which dumps to stdout all exchanges, and disables forking
@@ -279,7 +585,7 @@
line argument "-q".
-2) Proxies
+4. Proxies
----------
Proxy configuration can be located in a set of sections :
@@ -319,245 +625,18 @@
modifying, or removing arbitrary contents in requests or responses, based on
arbitrary criteria.
-
-2.1) Quick reminder about HTTP
-------------------------------
-
-When a proxy is running in HTTP mode, both the request and the response are
-fully analyzed and indexed, thus it becomes possible to build matching criteria
-on almost anything found in the contents.
-
-However, it is important to understand how HTTP requests and responses are
-formed, and how HAProxy decomposes them. It will then become easier to write
-correct rules and to debug existing configurations.
+4.1. Proxy keywords matrix
+--------------------------
-2.1.1) The HTTP transaction model
----------------------------------
+The following list of keywords is supported. Most of them may only be used in a
+limited set of section types. Some of them are marked as "deprecated" because
+they are inherited from an old syntax which may be confusing or functionally
+limited, and there are new recommended keywords to replace them. Keywords
+listed with [no] can be optionally inverted using the "no" prefix, ex. "no
+option contstats". This makes sense when the option has been enabled by default
+and must be disabled for a specific instance.
-The HTTP protocol is transaction-driven. This means that each request will lead
-to one and only one response. Traditionnally, a TCP connection is established
-from the client to the server, a request is sent by the client on the
-connection, the server responds and the connection is closed. A new request
-will involve a new connection :
-
- [CON1] [REQ1] ... [RESP1] [CLO1] [CON2] [REQ2] ... [RESP2] [CLO2] ...
-
-In this mode, called the "HTTP close" mode, there are as many connection
-establishments as there are HTTP transactions. Since the connection is closed
-by the server after the response, the client does not need to know the content
-length.
-
-Due to the transactional nature of the protocol, it was possible to improve it
-to avoid closing a connection between two subsequent transactions. In this mode
-however, it is mandatory that the server indicates the content length for each
-response so that the client does not wait indefinitely. For this, a special
-header is used: "Content-length". This mode is called the "keep-alive" mode :
-
- [CON] [REQ1] ... [RESP1] [REQ2] ... [RESP2] [CLO] ...
-
-Its advantages are a reduced latency between transactions, and less processing
-power required on the server side. It is generally better than the close mode,
-but not always because the clients often limit their concurrent connections to
-a smaller value. HAProxy currently does not support the HTTP keep-alive mode,
-but knows how to transform it to the close mode.
-
-A last improvement in the communications is the pipelining mode. It still uses
-keep-alive, but the client does not wait for the first response to send the
-second request. This is useful for fetching large number of images composing a
-page :
-
- [CON] [REQ1] [REQ2] ... [RESP1] [RESP2] [CLO] ...
-
-This can obviously have a tremendous benefit on performance because the network
-latency is eliminated between subsequent requests. Many HTTP agents do not
-correctly support pipelining since there is no way to associate a response with
-the corresponding request in HTTP. For this reason, it is mandatory for the
-server to reply in the exact same order as the requests were received.
-
-Right now, HAProxy only supports the first mode (HTTP close) if it needs to
-process the request. This means that for each request, there will be one TCP
-connection. If keep-alive or pipelining are required, HAProxy will still
-support them, but will only see the first request and the first response of
-each transaction. While this is generally problematic with regards to logs,
-content switching or filtering, it most often causes no problem for persistence
-with cookie insertion.
-
-
-2.1.2) HTTP request
--------------------
-
-First, let's consider this HTTP request :
-
- Line Contents
- number
- 1 GET /serv/login.php?lang=en&profile=2 HTTP/1.1
- 2 Host: www.mydomain.com
- 3 User-agent: my small browser
- 4 Accept: image/jpeg, image/gif
- 5 Accept: image/png
-
-
-2.1.2.1) The Request line
--------------------------
-
-Line 1 is the "request line". It is always composed of 3 fields :
-
- - a METHOD : GET
- - a URI : /serv/login.php?lang=en&profile=2
- - a version tag : HTTP/1.1
-
-All of them are delimited by what the standard calls LWS (linear white spaces),
-which are commonly spaces, but can also be tabs or line feeds/carriage returns
-followed by spaces/tabs. The method itself cannot contain any colon (':') and
-is limited to alphabetic letters. All those various combinations make it
-desirable that HAProxy performs the splitting itself rather than leaving it to
-the user to write a complex or inaccurate regular expression.
-
-The URI itself can have several forms :
-
- - A "relative URI" :
-
- /serv/login.php?lang=en&profile=2
-
- It is a complete URL without the host part. This is generally what is
- received by servers, reverse proxies and transparent proxies.
-
- - An "absolute URI", also called a "URL" :
-
- http://192.168.0.12:8080/serv/login.php?lang=en&profile=2
-
- It is composed of a "scheme" (the protocol name followed by '://'), a host
- name or address, optionally a colon (':') followed by a port number, then
- a relative URI beginning at the first slash ('/') after the address part.
- This is generally what proxies receive, but a server supporting HTTP/1.1
- must accept this form too.
-
- - a star ('*') : this form is only accepted in association with the OPTIONS
- method and is not relayable. It is used to inquiry a next hop's
- capabilities.
-
- - an address:port combination : 192.168.0.12:80
- This is used with the CONNECT method, which is used to establish TCP
- tunnels through HTTP proxies, generally for HTTPS, but sometimes for
- other protocols too.
-
-In a relative URI, two sub-parts are identified. The part before the question
-mark is called the "path". It is typically the relative path to static objects
-on the server. The part after the question mark is called the "query string".
-It is mostly used with GET requests sent to dynamic scripts and is very
-specific to the language, framework or application in use.
-
-
-2.1.2.2) The request headers
-----------------------------
-
-The headers start at the second line. They are composed of a name at the
-beginning of the line, immediately followed by a colon (':'). Traditionally,
-an LWS is added after the colon but that's not required. Then come the values.
-Multiple identical headers may be folded into one single line, delimiting the
-values with commas, provided that their order is respected. This is commonly
-encountered in the "Cookie:" field. A header may span over multiple lines if
-the subsequent lines begin with an LWS. In the example in 2.1.2, lines 4 and 5
-define a total of 3 values for the "Accept:" header.
-
-Contrary to a common mis-conception, header names are not case-sensitive, and
-their values are not either if they refer to other header names (such as the
-"Connection:" header).
-
-The end of the headers is indicated by the first empty line. People often say
-that it's a double line feed, which is not exact, even if a double line feed
-is one valid form of empty line.
-
-Fortunately, HAProxy takes care of all these complex combinations when indexing
-headers, checking values and counting them, so there is no reason to worry
-about the way they could be written, but it is important not to accuse an
-application of being buggy if it does unusual, valid things.
-
-Important note:
- As suggested by RFC2616, HAProxy normalizes headers by replacing line breaks
- in the middle of headers by LWS in order to join multi-line headers. This
- is necessary for proper analysis and helps less capable HTTP parsers to work
- correctly and not to be fooled by such complex constructs.
-
-
-2.1.3) HTTP response
---------------------
-
-An HTTP response looks very much like an HTTP request. Both are called HTTP
-messages. Let's consider this HTTP response :
-
- Line Contents
- number
- 1 HTTP/1.1 200 OK
- 2 Content-length: 350
- 3 Content-Type: text/html
-
-
-2.1.3.1) The Response line
---------------------------
-
-Line 1 is the "response line". It is always composed of 3 fields :
-
- - a version tag : HTTP/1.1
- - a status code : 200
- - a reason : OK
-
-The status code is always 3-digit. The first digit indicates a general status :
- - 2xx = OK, content is following (eg: 200, 206)
- - 3xx = OK, no content following (eg: 302, 304)
- - 4xx = error caused by the client (eg: 401, 403, 404)
- - 5xx = error caused by the server (eg: 500, 502, 503)
-
-Please refer to RFC2616 for the detailed meaning of all such codes. The
-"reason" field is just a hint, but is not parsed by clients. Anything can be
-found there, but it's a common practice to respect the well-established
-messages. It can be composed of one or multiple words, such as "OK", "Found",
-or "Authentication Required".
-
-Haproxy may emit the following status codes by itself :
-
- Code When / reason
- 200 access to stats page, and when replying to monitoring requests
- 301 when performing a redirection, depending on the configured code
- 302 when performing a redirection, depending on the configured code
- 303 when performing a redirection, depending on the configured code
- 400 for an invalid or too large request
- 401 when an authentication is required to perform the action (when
- accessing the stats page)
- 403 when a request is forbidden by a "block" ACL or "reqdeny" filter
- 408 when the request timeout strikes before the request is complete
- 500 when haproxy encounters an unrecoverable internal error, such as a
- memory allocation failure, which should never happen
- 502 when the server returns an empty, invalid or incomplete response, or
- when an "rspdeny" filter blocks the response.
- 503 when no server was available to handle the request, or in response to
- monitoring requests which match the "monitor fail" condition
- 504 when the response timeout strikes before the server responds
-
-The error 4xx and 5xx codes above may be customized (see "errorloc" in section
-2.2).
-
-
-2.1.3.2) The response headers
------------------------------
-
-Response headers work exactly like request headers, and as such, HAProxy uses
-the same parsing function for both. Please refer to paragraph 2.1.2.2 for more
-details.
-
-
-2.2) Proxy keywords matrix
---------------------------
-
-The following list of keywords is supported. Most of them may only be used in a
-limited set of section types. Some of them are marked as "deprecated" because
-they are inherited from an old syntax which may be confusing or functionally
-limited, and there are new recommended keywords to replace them. Keywords
-listed with [no] can be optionally inverted using the "no" prefix, ex. "no
-option contstats". This makes sense when the option has been enabled by default
-and must be disabled for a specific instance.
-
keyword defaults frontend listen backend
----------------------+----------+----------+---------+---------
@@ -681,8 +760,8 @@
keyword defaults frontend listen backend
-2.2.1) Alphabetically sorted keywords reference
------------------------------------------------
+4.2. Alphabetically sorted keywords reference
+---------------------------------------------
This section provides a description of each keyword and its usage.
@@ -696,7 +775,7 @@
acl invalid_src src_port 0:1023
acl local_dst hdr(host) -i localhost
- See section 2.3 about ACL usage.
+ See section 7 about ACL usage.
appsession <cookie> len <length> timeout <holdtime>
@@ -1018,7 +1097,7 @@
The HTTP request will be blocked very early in the layer 7 processing
if/unless <condition> is matched. A 403 error will be returned if the request
- is blocked. The condition has to reference ACLs (see section 2.3). This is
+ is blocked. The condition has to reference ACLs (see section 7). This is
typically used to deny access to certain sensible resources if some
conditions are met or not met. There is no fixed limit to the number of
"block" statements per instance.
@@ -1029,7 +1108,7 @@
acl local_dst hdr(host) -i localhost
block if invalid_src || local_dst
- See section 2.3 about ACL usage.
+ See section 7 about ACL usage.
capture cookie <name> len <length>
@@ -1068,7 +1147,7 @@
capture cookie ASPSESSION len 32
See also : "capture request header", "capture response header" as well as
- section 2.6 about logging.
+ section 8 about logging.
capture request header <name> len <length>
@@ -1111,7 +1190,7 @@
capture request header X-Forwarded-For len 15
capture request header Referrer len 15
- See also : "capture cookie", "capture response header" as well as section 2.6
+ See also : "capture cookie", "capture response header" as well as section 8
about logging.
@@ -1148,7 +1227,7 @@
capture response header Content-length len 9
capture response header Location len 15
- See also : "capture cookie", "capture request header" as well as section 2.6
+ See also : "capture cookie", "capture request header" as well as section 8
about logging.
@@ -2022,7 +2101,7 @@
complex issues is in the normal logs which will not be logged here. If you
need to separate logs, see the "log-separate-errors" option instead.
- See also : "log", "dontlognull", "log-separate-errors" and section 2.6 about
+ See also : "log", "dontlognull", "log-separate-errors" and section 8 about
logging.
@@ -2048,7 +2127,7 @@
If this option has been enabled in a "defaults" section, it can be disabled
in a specific instance by prepending the "no" keyword before it.
- See also : "log", "monitor-net", "monitor-uri" and section 2.6 about logging.
+ See also : "log", "monitor-net", "monitor-uri" and section 8 about logging.
option forceclose
@@ -2191,7 +2270,7 @@
yes | yes | yes | yes
Arguments : none
- As stated in section 2.1, HAProxy does not yes support the HTTP keep-alive
+ As stated in section 1, HAProxy does not yes support the HTTP keep-alive
mode. So by default, if a client communicates with a server in this mode, it
will only analyze, log, and process the first request of each connection. To
workaround this limitation, it is possible to specify "option httpclose". It
@@ -2233,7 +2312,7 @@
This option may be set either in the frontend or the backend.
- See also : section 2.6 about logging.
+ See also : section 8 about logging.
option http_proxy
@@ -2287,7 +2366,7 @@
second may log normal traffic to a rotating buffer and only archive smaller
error logs.
- See also : "log", "dontlognull", "dontlog-normal" and section 2.6 about
+ See also : "log", "dontlognull", "dontlog-normal" and section 8 about
logging.
@@ -2321,7 +2400,7 @@
static/srv1 9/10/7/14/+30 200 +243 - - ---- 3/1/1/1/0 1/0 \
"GET /image.iso HTTP/1.0"
- See also : "option httplog", "capture response header", and section 2.6 about
+ See also : "option httplog", "capture response header", and section 8 about
logging.
@@ -2704,7 +2783,7 @@
This option may be set either in the frontend or the backend.
- See also : "option httplog", and section 2.6 about logging.
+ See also : "option httplog", and section 8 about logging.
option tcpsplice [ experimental ]
@@ -2854,7 +2933,7 @@
redirect location http://mysite.com/ if !login_page secure
redirect location / clear-cookie USERID= if logout
- See section 2.3 about ACL usage.
+ See section 7 about ACL usage.
redisp (deprecated)
@@ -2888,7 +2967,7 @@
Arguments :
<string> is the complete line to be added. Any space or known delimiter
must be escaped using a backslash ('\'). Please refer to section
- 2.5 about HTTP header manipulation for more information.
+ 6 about HTTP header manipulation for more information.
A new line consisting in <string> followed by a line feed will be added after
the last header of an HTTP request.
@@ -2897,7 +2976,7 @@
and not to traffic generated by HAProxy, such as health-checks or error
responses.
- See also: "rspadd" and section 2.5 about HTTP header manipulation
+ See also: "rspadd" and section 6 about HTTP header manipulation
reqallow <search>
@@ -2928,7 +3007,7 @@
reqiallow ^Host:\ www\.
reqideny ^Host:\ .*\.local
- See also: "reqdeny", "acl", "block" and section 2.5 about HTTP header
+ See also: "reqdeny", "acl", "block" and section 6 about HTTP header
manipulation
@@ -2959,7 +3038,7 @@
reqidel ^X-Forwarded-For:.*
reqidel ^Cookie:.*SERVER=
- See also: "reqadd", "reqrep", "rspdel" and section 2.5 about HTTP header
+ See also: "reqadd", "reqrep", "rspdel" and section 6 about HTTP header
manipulation
@@ -2995,7 +3074,7 @@
reqideny ^Host:\ .*\.local
reqiallow ^Host:\ www\.
- See also: "reqallow", "rspdeny", "acl", "block" and section 2.5 about HTTP
+ See also: "reqallow", "rspdeny", "acl", "block" and section 6 about HTTP
header manipulation
@@ -3027,7 +3106,7 @@
reqideny ^Host:\ .*\.local
reqiallow ^Host:\ www\.
- See also: "reqallow", "reqdeny", "acl", "block" and section 2.5 about HTTP
+ See also: "reqallow", "reqdeny", "acl", "block" and section 6 about HTTP
header manipulation
@@ -3048,7 +3127,7 @@
must be escaped using a backslash ('\'). References to matched
pattern groups are possible using the common \N form, with N
being a single digit between 0 and 9. Please refer to section
- 2.5 about HTTP header manipulation for more information.
+ 6 about HTTP header manipulation for more information.
Any line matching extended regular expression <search> in the request (both
the request line and header lines) will be completely replaced with <string>.
@@ -3066,7 +3145,7 @@
# replace "www.mydomain.com" with "www" in the host name.
reqirep ^Host:\ www.mydomain.com Host:\ www
- See also: "reqadd", "reqdel", "rsprep" and section 2.5 about HTTP header
+ See also: "reqadd", "reqdel", "rsprep" and section 6 about HTTP header
manipulation
@@ -3104,7 +3183,7 @@
reqipass ^User-Agent:\.*(Mozilla|MSIE)
reqitarpit ^User-Agent:
- See also: "reqallow", "reqdeny", "reqpass", and section 2.5 about HTTP header
+ See also: "reqallow", "reqdeny", "reqpass", and section 6 about HTTP header
manipulation
@@ -3137,7 +3216,7 @@
Arguments :
<string> is the complete line to be added. Any space or known delimiter
must be escaped using a backslash ('\'). Please refer to section
- 2.5 about HTTP header manipulation for more information.
+ 6 about HTTP header manipulation for more information.
A new line consisting in <string> followed by a line feed will be added after
the last header of an HTTP response.
@@ -3146,7 +3225,7 @@
and not to traffic generated by HAProxy, such as health-checks or error
responses.
- See also: "reqadd" and section 2.5 about HTTP header manipulation
+ See also: "reqadd" and section 6 about HTTP header manipulation
rspdel <search>
@@ -3176,7 +3255,7 @@
# remove the Server header from responses
reqidel ^Server:.*
- See also: "rspadd", "rsprep", "reqdel" and section 2.5 about HTTP header
+ See also: "rspadd", "rsprep", "reqdel" and section 6 about HTTP header
manipulation
@@ -3211,7 +3290,7 @@
# Ensure that no content type matching ms-word will leak
rspideny ^Content-type:\.*/ms-word
- See also: "reqdeny", "acl", "block" and section 2.5 about HTTP header
+ See also: "reqdeny", "acl", "block" and section 6 about HTTP header
manipulation
@@ -3233,7 +3312,7 @@
must be escaped using a backslash ('\'). References to matched
pattern groups are possible using the common \N form, with N
being a single digit between 0 and 9. Please refer to section
- 2.5 about HTTP header manipulation for more information.
+ 6 about HTTP header manipulation for more information.
Any line matching extended regular expression <search> in the response (both
the response line and header lines) will be completely replaced with
@@ -3249,7 +3328,7 @@
# replace "Location: 127.0.0.1:8080" with "Location: www.mydomain.com"
rspirep ^Location:\ 127.0.0.1:8080 Location:\ www.mydomain.com
- See also: "rspadd", "rspdel", "reqrep" and section 2.5 about HTTP header
+ See also: "rspadd", "rspdel", "reqrep" and section 6 about HTTP header
manipulation
@@ -3273,13 +3352,13 @@
<param*> is a list of parameters for this server. The "server" keywords
accepts an important number of options and has a complete section
- dedicated to it. Please refer to section 2.4 for more details.
+ dedicated to it. Please refer to section 5 for more details.
Examples :
server first 10.1.1.1:1080 cookie first check inter 1000
server second 10.1.1.2:1080 cookie second check inter 1000
- See also : section 2.4 about server options
+ See also : section 5 about server options
source <addr>[:<port>] [usesrc { <addr2>[:<port2>] | client | clientip } ]
@@ -3358,7 +3437,7 @@
This option sets the default source for all servers in the backend. It may
also be specified in a "defaults" section. Finer source address specification
is possible at the server level using the "source" server option. Refer to
- section 2.4 for more information.
+ section 5 for more information.
Examples :
backend private
@@ -3384,7 +3463,7 @@
# with Tproxy version 4.
source 0.0.0.0 usesrc clientip
- See also : the "source" server option in section 2.4, the Tproxy patches for
+ See also : the "source" server option in section 5, the Tproxy patches for
the Linux kernel on www.balabit.com, the "bind" keyword.
@@ -3746,7 +3825,7 @@
"accept". Thus, this statement alone does not bring anything without another
"reject" statement.
- See section 2.3 about ACL usage.
+ See section 7 about ACL usage.
See also : "tcp-request content reject", "tcp-request inspect-delay"
@@ -3783,7 +3862,7 @@
tcp-request accept if content_present
tcp-request reject
- See section 2.3 about ACL usage.
+ See section 7 about ACL usage.
See also : "tcp-request content accept", "tcp-request inspect-delay"
@@ -4080,7 +4159,7 @@
Arguments :
<backend> is the name of a valid backend or "listen" section.
- <condition> is a condition composed of ACLs, as described in section 2.3.
+ <condition> is a condition composed of ACLs, as described in section 7.
When doing content-switching, connections arrive on a frontend and are then
dispatched to various backends depending on a number of conditions. The
@@ -4098,42 +4177,332 @@
used (in case of a "listen" section) or, in case of a frontend, no server is
used and a 503 service unavailable response is returned.
- See also: "default_backend" and section 2.3 about ACLs.
+ See also: "default_backend" and section 7 about ACLs.
-2.3) Using ACLs
----------------
-
-The use of Access Control Lists (ACL) provides a flexible solution to perform
-content switching and generally to take decisions based on content extracted
-from the request, the response or any environmental status. The principle is
-simple :
-
- - define test criteria with sets of values
- - perform actions only if a set of tests is valid
-
-The actions generally consist in blocking the request, or selecting a backend.
-
-In order to define a test, the "acl" keyword is used. The syntax is :
+5. Server options
+-----------------
- acl <aclname> <criterion> [flags] [operator] <value> ...
+The "server" keyword supports a certain number of settings which are all passed
+as arguments on the server line. The order in which those arguments appear does
+not count, and they are all optional. Some of those settings are single words
+(booleans) while others expect one or several values after them. In this case,
+the values must immediately follow the setting name. All those settings must be
+specified after the server's address if they are used :
-This creates a new ACL <aclname> or completes an existing one with new tests.
-Those tests apply to the portion of request/response specified in <criterion>
-and may be adjusted with optional flags [flags]. Some criteria also support
-an operator which may be specified before the set of values. The values are
-of the type supported by the criterion, and are separated by spaces.
+ server <name> <address>[:port] [settings ...]
-ACL names must be formed from upper and lower case letters, digits, '-' (dash),
-'_' (underscore) , '.' (dot) and ':' (colon). ACL names are case-sensitive,
-which means that "my_acl" and "My_Acl" are two different ACLs.
+The currently supported settings are the following ones.
-There is no enforced limit to the number of ACLs. The unused ones do not affect
-performance, they just consume a small amount of memory.
+addr <ipv4>
+ Using the "addr" parameter, it becomes possible to use a different IP address
+ to send health-checks. On some servers, it may be desirable to dedicate an IP
+ address to specific component able to perform complex tests which are more
+ suitable to health-checks than the application. This parameter is ignored if
+ the "check" parameter is not set. See also the "port" parameter.
-The following ACL flags are currently supported :
+backup
+ When "backup" is present on a server line, the server is only used in load
+ balancing when all other non-backup servers are unavailable. Requests coming
+ with a persistence cookie referencing the server will always be served
+ though. By default, only the first operational backup server is used, unless
+ the "allbackups" option is set in the backend. See also the "allbackups"
+ option.
- -i : ignore case during matching.
+check
+ This option enables health checks on the server. By default, a server is
+ always considered available. If "check" is set, the server will receive
+ periodic health checks to ensure that it is really able to serve requests.
+ The default address and port to send the tests to are those of the server,
+ and the default source is the same as the one defined in the backend. It is
+ possible to change the address using the "addr" parameter, the port using the
+ "port" parameter, the source address using the "source" address, and the
+ interval and timers using the "inter", "rise" and "fall" parameters. The
+ request method is define in the backend using the "httpchk", "smtpchk",
+ and "ssl-hello-chk" options. Please refer to those options and parameters for
+ more information.
+
+cookie <value>
+ The "cookie" parameter sets the cookie value assigned to the server to
+ <value>. This value will be checked in incoming requests, and the first
+ operational server possessing the same value will be selected. In return, in
+ cookie insertion or rewrite modes, this value will be assigned to the cookie
+ sent to the client. There is nothing wrong in having several servers sharing
+ the same cookie value, and it is in fact somewhat common between normal and
+ backup servers. See also the "cookie" keyword in backend section.
+
+fall <count>
+ The "fall" parameter states that a server will be considered as dead after
+ <count> consecutive unsuccessful health checks. This value defaults to 3 if
+ unspecified. See also the "check", "inter" and "rise" parameters.
+
+id <value>
+ Set a persistent value for server ID. Must be unique and larger than 1000, as
+ smaller values are reserved for auto-assigned ids.
+
+inter <delay>
+fastinter <delay>
+downinter <delay>
+ The "inter" parameter sets the interval between two consecutive health checks
+ to <delay> milliseconds. If left unspecified, the delay defaults to 2000 ms.
+ It is also possible to use "fastinter" and "downinter" to optimize delays
+ between checks depending on the server state :
+
+ Server state | Interval used
+ ---------------------------------+-----------------------------------------
+ UP 100% (non-transitional) | "inter"
+ ---------------------------------+-----------------------------------------
+ Transitionally UP (going down), |
+ Transitionally DOWN (going up), | "fastinter" if set, "inter" otherwise.
+ or yet unchecked. |
+ ---------------------------------+-----------------------------------------
+ DOWN 100% (non-transitional) | "downinter" if set, "inter" otherwise.
+ ---------------------------------+-----------------------------------------
+
+ Just as with every other time-based parameter, they can be entered in any
+ other explicit unit among { us, ms, s, m, h, d }. The "inter" parameter also
+ serves as a timeout for health checks sent to servers if "timeout check" is
+ not set. In order to reduce "resonance" effects when multiple servers are
+ hosted on the same hardware, the health-checks of all servers are started
+ with a small time offset between them. It is also possible to add some random
+ noise in the health checks interval using the global "spread-checks"
+ keyword. This makes sense for instance when a lot of backends use the same
+ servers.
+
+maxconn <maxconn>
+ The "maxconn" parameter specifies the maximal number of concurrent
+ connections that will be sent to this server. If the number of incoming
+ concurrent requests goes higher than this value, they will be queued, waiting
+ for a connection to be released. This parameter is very important as it can
+ save fragile servers from going down under extreme loads. If a "minconn"
+ parameter is specified, the limit becomes dynamic. The default value is "0"
+ which means unlimited. See also the "minconn" and "maxqueue" parameters, and
+ the backend's "fullconn" keyword.
+
+maxqueue <maxqueue>
+ The "maxqueue" parameter specifies the maximal number of connections which
+ will wait in the queue for this server. If this limit is reached, next
+ requests will be redispatched to other servers instead of indefinitely
+ waiting to be served. This will break persistence but may allow people to
+ quickly re-log in when the server they try to connect to is dying. The
+ default value is "0" which means the queue is unlimited. See also the
+ "maxconn" and "minconn" parameters.
+
+minconn <minconn>
+ When the "minconn" parameter is set, the maxconn limit becomes a dynamic
+ limit following the backend's load. The server will always accept at least
+ <minconn> connections, never more than <maxconn>, and the limit will be on
+ the ramp between both values when the backend has less than <fullconn>
+ concurrent connections. This makes it possible to limit the load on the
+ server during normal loads, but push it further for important loads without
+ overloading the server during exceptionnal loads. See also the "maxconn"
+ and "maxqueue" parameters, as well as the "fullconn" backend keyword.
+
+port <port>
+ Using the "port" parameter, it becomes possible to use a different port to
+ send health-checks. On some servers, it may be desirable to dedicate a port
+ to a specific component able to perform complex tests which are more suitable
+ to health-checks than the application. It is common to run a simple script in
+ inetd for instance. This parameter is ignored if the "check" parameter is not
+ set. See also the "addr" parameter.
+
+redir <prefix>
+ The "redir" parameter enables the redirection mode for all GET and HEAD
+ requests addressing this server. This means that instead of having HAProxy
+ forward the request to the server, it will send an "HTTP 302" response with
+ the "Location" header composed of this prefix immediately followed by the
+ requested URI beginning at the leading '/' of the path component. That means
+ that no trailing slash should be used after <prefix>. All invalid requests
+ will be rejected, and all non-GET or HEAD requests will be normally served by
+ the server. Note that since the response is completely forged, no header
+ mangling nor cookie insertion is possible in the respose. However, cookies in
+ requests are still analysed, making this solution completely usable to direct
+ users to a remote location in case of local disaster. Main use consists in
+ increasing bandwidth for static servers by having the clients directly
+ connect to them. Note: never use a relative location here, it would cause a
+ loop between the client and HAProxy!
+
+ Example : server srv1 192.168.1.1:80 redir http://image1.mydomain.com check
+
+rise <count>
+ The "rise" parameter states that a server will be considered as operational
+ after <count> consecutive successful health checks. This value defaults to 2
+ if unspecified. See also the "check", "inter" and "fall" parameters.
+
+slowstart <start_time_in_ms>
+ The "slowstart" parameter for a server accepts a value in milliseconds which
+ indicates after how long a server which has just come back up will run at
+ full speed. Just as with every other time-based parameter, it can be entered
+ in any other explicit unit among { us, ms, s, m, h, d }. The speed grows
+ linearly from 0 to 100% during this time. The limitation applies to two
+ parameters :
+
+ - maxconn: the number of connections accepted by the server will grow from 1
+ to 100% of the usual dynamic limit defined by (minconn,maxconn,fullconn).
+
+ - weight: when the backend uses a dynamic weighted algorithm, the weight
+ grows linearly from 1 to 100%. In this case, the weight is updated at every
+ health-check. For this reason, it is important that the "inter" parameter
+ is smaller than the "slowstart", in order to maximize the number of steps.
+
+ The slowstart never applies when haproxy starts, otherwise it would cause
+ trouble to running servers. It only applies when a server has been previously
+ seen as failed.
+
+source <addr>[:<port>] [usesrc { <addr2>[:<port2>] | client | clientip } ]
+source <addr>[:<port>] [interface <name>] ...
+ The "source" parameter sets the source address which will be used when
+ connecting to the server. It follows the exact same parameters and principle
+ as the backend "source" keyword, except that it only applies to the server
+ referencing it. Please consult the "source" keyword for details.
+
+track [<proxy>/]<server>
+ This option enables ability to set the current state of the server by
+ tracking another one. Only a server with checks enabled can be tracked
+ so it is not possible for example to track a server that tracks another
+ one. If <proxy> is omitted the current one is used. If disable-on-404 is
+ used, it has to be enabled on both proxies.
+
+weight <weight>
+ The "weight" parameter is used to adjust the server's weight relative to
+ other servers. All servers will receive a load proportional to their weight
+ relative to the sum of all weights, so the higher the weight, the higher the
+ load. The default weight is 1, and the maximal value is 255. If this
+ parameter is used to distribute the load according to server's capacity, it
+ is recommended to start with values which can both grow and shrink, for
+ instance between 10 and 100 to leave enough room above and below for later
+ adjustments.
+
+
+6. HTTP header manipulation
+---------------------------
+
+In HTTP mode, it is possible to rewrite, add or delete some of the request and
+response headers based on regular expressions. It is also possible to block a
+request or a response if a particular header matches a regular expression,
+which is enough to stop most elementary protocol attacks, and to protect
+against information leak from the internal network. But there is a limitation
+to this : since HAProxy's HTTP engine does not support keep-alive, only headers
+passed during the first request of a TCP session will be seen. All subsequent
+headers will be considered data only and not analyzed. Furthermore, HAProxy
+never touches data contents, it stops analysis at the end of headers.
+
+This section covers common usage of the following keywords, described in detail
+in section 4.2 :
+
+ - reqadd <string>
+ - reqallow <search>
+ - reqiallow <search>
+ - reqdel <search>
+ - reqidel <search>
+ - reqdeny <search>
+ - reqideny <search>
+ - reqpass <search>
+ - reqipass <search>
+ - reqrep <search> <replace>
+ - reqirep <search> <replace>
+ - reqtarpit <search>
+ - reqitarpit <search>
+ - rspadd <string>
+ - rspdel <search>
+ - rspidel <search>
+ - rspdeny <search>
+ - rspideny <search>
+ - rsprep <search> <replace>
+ - rspirep <search> <replace>
+
+With all these keywords, the same conventions are used. The <search> parameter
+is a POSIX extended regular expression (regex) which supports grouping through
+parenthesis (without the backslash). Spaces and other delimiters must be
+prefixed with a backslash ('\') to avoid confusion with a field delimiter.
+Other characters may be prefixed with a backslash to change their meaning :
+
+ \t for a tab
+ \r for a carriage return (CR)
+ \n for a new line (LF)
+ \ to mark a space and differentiate it from a delimiter
+ \# to mark a sharp and differentiate it from a comment
+ \\ to use a backslash in a regex
+ \\\\ to use a backslash in the text (*2 for regex, *2 for haproxy)
+ \xXX to write the ASCII hex code XX as in the C language
+
+The <replace> parameter contains the string to be used to replace the largest
+portion of text matching the regex. It can make use of the special characters
+above, and can reference a substring which is delimited by parenthesis in the
+regex, by writing a backslash ('\') immediately followed by one digit from 0 to
+9 indicating the group position (0 designating the entire line). This practice
+is very common to users of the "sed" program.
+
+The <string> parameter represents the string which will systematically be added
+after the last header line. It can also use special character sequences above.
+
+Notes related to these keywords :
+---------------------------------
+ - these keywords are not always convenient to allow/deny based on header
+ contents. It is strongly recommended to use ACLs with the "block" keyword
+ instead, resulting in far more flexible and manageable rules.
+
+ - lines are always considered as a whole. It is not possible to reference
+ a header name only or a value only. This is important because of the way
+ headers are written (notably the number of spaces after the colon).
+
+ - the first line is always considered as a header, which makes it possible to
+ rewrite or filter HTTP requests URIs or response codes, but in turn makes
+ it harder to distinguish between headers and request line. The regex prefix
+ ^[^\ \t]*[\ \t] matches any HTTP method followed by a space, and the prefix
+ ^[^ \t:]*: matches any header name followed by a colon.
+
+ - for performances reasons, the number of characters added to a request or to
+ a response is limited at build time to values between 1 and 4 kB. This
+ should normally be far more than enough for most usages. If it is too short
+ on occasional usages, it is possible to gain some space by removing some
+ useless headers before adding new ones.
+
+ - keywords beginning with "reqi" and "rspi" are the same as their couterpart
+ without the 'i' letter except that they ignore case when matching patterns.
+
+ - when a request passes through a frontend then a backend, all req* rules
+ from the frontend will be evaluated, then all req* rules from the backend
+ will be evaluated. The reverse path is applied to responses.
+
+ - req* statements are applied after "block" statements, so that "block" is
+ always the first one, but before "use_backend" in order to permit rewriting
+ before switching.
+
+
+7. Using ACLs
+-------------
+
+The use of Access Control Lists (ACL) provides a flexible solution to perform
+content switching and generally to take decisions based on content extracted
+from the request, the response or any environmental status. The principle is
+simple :
+
+ - define test criteria with sets of values
+ - perform actions only if a set of tests is valid
+
+The actions generally consist in blocking the request, or selecting a backend.
+
+In order to define a test, the "acl" keyword is used. The syntax is :
+
+ acl <aclname> <criterion> [flags] [operator] <value> ...
+
+This creates a new ACL <aclname> or completes an existing one with new tests.
+Those tests apply to the portion of request/response specified in <criterion>
+and may be adjusted with optional flags [flags]. Some criteria also support
+an operator which may be specified before the set of values. The values are
+of the type supported by the criterion, and are separated by spaces.
+
+ACL names must be formed from upper and lower case letters, digits, '-' (dash),
+'_' (underscore) , '.' (dot) and ':' (colon). ACL names are case-sensitive,
+which means that "my_acl" and "My_Acl" are two different ACLs.
+
+There is no enforced limit to the number of ACLs. The unused ones do not affect
+performance, they just consume a small amount of memory.
+
+The following ACL flags are currently supported :
+
+ -i : ignore case during matching.
-- : force end of flags. Useful when a string looks like one of the flags.
Supported types of values are :
@@ -4144,8 +4513,8 @@
- IP addresses and networks
-2.3.1) Matching integers
-------------------------
+7.1. Matching integers
+----------------------
Matching integers is special in that ranges and operators are permitted. Note
that integer matching only applies to positive values. A range is a value
@@ -4183,8 +4552,8 @@
acl sslv3 req_ssl_ver 3:3.1
-2.3.2) Matching strings
------------------------
+7.2. Matching strings
+---------------------
String matching applies to verbatim strings as they are passed, with the
exception of the backslash ("\") which makes it possible to escape some
@@ -4194,8 +4563,8 @@
before the first string. Same applies of course to match the string "--".
-2.3.3) Matching regular expressions (regexes)
----------------------------------------------
+7.3. Matching regular expressions (regexes)
+-------------------------------------------
Just like with string matching, regex matching applies to verbatim strings as
they are passed, with the exception of the backslash ("\") which makes it
@@ -4206,8 +4575,8 @@
match the string "--".
-2.3.4) Matching IPv4 addresses
-------------------------------
+7.4. Matching IPv4 addresses
+----------------------------
IPv4 addresses values can be specified either as plain addresses or with a
netmask appended, in which case the IPv4 address matches whenever it is
@@ -4219,11 +4588,11 @@
parsed.
-2.3.5) Available matching criteria
-----------------------------------
+7.5. Available matching criteria
+--------------------------------
-2.3.5.1) Matching at Layer 4 and below
---------------------------------------
+7.5.1. Matching at Layer 4 and below
+------------------------------------
A first set of criteria applies to information which does not require any
analysis of the request or response contents. Those generally include TCP/IP
@@ -4328,8 +4697,8 @@
redirect location /denied.html if being_scanned
-2.3.5.2) Matching contents at Layer 4
--------------------------------------
+7.5.2. Matching contents at Layer 4
+-----------------------------------
A second set of criteria depends on data found in buffers, but which can change
during analysis. This requires that some data has been buffered, for instance
@@ -4378,8 +4747,8 @@
tcp-request content reject
-2.3.5.3) Matching at Layer 7
-----------------------------
+7.5.3. Matching at Layer 7
+--------------------------
A third set of criteria applies to information which can be found at the
application layer (layer 7). Those require that a full HTTP request has been
@@ -4482,426 +4851,136 @@
match any of the strings. This can be used to check exact for values. For
instance, checking that "connection: close" is set :
- hdr(Connection) -i close
-
-hdr_beg <string>
-hdr_beg(header) <string>
- Returns true when one of the headers begins with one of the strings. See
- "hdr" for more information on header matching.
-
-hdr_end <string>
-hdr_end(header) <string>
- Returns true when one of the headers ends with one of the strings. See "hdr"
- for more information on header matching.
-
-hdr_sub <string>
-hdr_sub(header) <string>
- Returns true when one of the headers contains one of the strings. See "hdr"
- for more information on header matching.
-
-hdr_dir <string>
-hdr_dir(header) <string>
- Returns true when one of the headers contains one of the strings either
- isolated or delimited by slashes. This is used to perform filename or
- directory name matching, and may be used with Referer. See "hdr" for more
- information on header matching.
-
-hdr_dom <string>
-hdr_dom(header) <string>
- Returns true when one of the headers contains one of the strings either
- isolated or delimited by dots. This is used to perform domain name matching,
- and may be used with the Host header. See "hdr" for more information on
- header matching.
-
-hdr_reg <regex>
-hdr_reg(header) <regex>
- Returns true when one of the headers matches of the regular expressions. It
- can be used at any time, but it is important to remember that regex matching
- is slower than other methods. See also other "hdr_" criteria, as well as
- "hdr" for more information on header matching.
-
-hdr_val <integer>
-hdr_val(header) <integer>
- Returns true when one of the headers starts with a number which matches the
- values or ranges specified. This may be used to limit content-length to
- acceptable values for example. See "hdr" for more information on header
- matching.
-
-hdr_cnt <integer>
-hdr_cnt(header) <integer>
- Returns true when the number of occurrence of the specified header matches
- the values or ranges specified. It is important to remember that one header
- line may count as several headers if it has several values. This is used to
- detect presence, absence or abuse of a specific header, as well as to block
- request smugling attacks by rejecting requests which contain more than one
- of certain headers. See "hdr" for more information on header matching.
-
-
-2.3.6) Pre-defined ACLs
------------------------
-
-Some predefined ACLs are hard-coded so that they do not have to be declared in
-every frontend which needs them. They all have their names in upper case in
-order to avoid confusion. Their equivalence is provided below. Please note that
-only the first three ones are not layer 7 based.
-
-ACL name Equivalent to Usage
----------------+-----------------------------+---------------------------------
-TRUE always_true always match
-FALSE always_false never match
-LOCALHOST src 127.0.0.1/8 match connection from local host
-HTTP_1.0 req_ver 1.0 match HTTP version 1.0
-HTTP_1.1 req_ver 1.1 match HTTP version 1.1
-METH_CONNECT method CONNECT match HTTP CONNECT method
-METH_GET method GET HEAD match HTTP GET or HEAD method
-METH_HEAD method HEAD match HTTP HEAD method
-METH_OPTIONS method OPTIONS match HTTP OPTIONS method
-METH_POST method POST match HTTP POST method
-METH_TRACE method TRACE match HTTP TRACE method
-HTTP_URL_ABS url_reg ^[^/:]*:// match absolute URL with scheme
-HTTP_URL_SLASH url_beg / match URL begining with "/"
-HTTP_URL_STAR url * match URL equal to "*"
-HTTP_CONTENT hdr_val(content-length) gt 0 match an existing content-length
-REQ_CONTENT req_len gt 0 match data in the request buffer
-WAIT_END wait_end wait for end of content analysis
----------------+-----------------------------+---------------------------------
-
-
-2.3.7) Using ACLs to form conditions
-------------------------------------
-
-Some actions are only performed upon a valid condition. A condition is a
-combination of ACLs with operators. 3 operators are supported :
-
- - AND (implicit)
- - OR (explicit with the "or" keyword or the "||" operator)
- - Negation with the exclamation mark ("!")
-
-A condition is formed as a disjonctive form :
-
- [!]acl1 [!]acl2 ... [!]acln { or [!]acl1 [!]acl2 ... [!]acln } ...
-
-Such conditions are generally used after an "if" or "unless" statement,
-indicating when the condition will trigger the action.
-
-For instance, to block HTTP requests to the "*" URL with methods other than
-"OPTIONS", as well as POST requests without content-length, and GET or HEAD
-requests with a content-length greater than 0, and finally every request which
-is not either GET/HEAD/POST/OPTIONS !
-
- acl missing_cl hdr_cnt(Content-length) eq 0
- block if HTTP_URL_STAR !METH_OPTIONS || METH_POST missing_cl
- block if METH_GET HTTP_CONTENT
- block unless METH_GET or METH_POST or METH_OPTIONS
-
-To select a different backend for requests to static contents on the "www" site
-and to every request on the "img", "video", "download" and "ftp" hosts :
-
- acl url_static path_beg /static /images /img /css
- acl url_static path_end .gif .png .jpg .css .js
- acl host_www hdr_beg(host) -i www
- acl host_static hdr_beg(host) -i img. video. download. ftp.
-
- # now use backend "static" for all static-only hosts, and for static urls
- # of host "www". Use backend "www" for the rest.
- use_backend static if host_static or host_www url_static
- use_backend www if host_www
-
-See section 2.2 for detailed help on the "block" and "use_backend" keywords.
-
-
-2.4) Server options
--------------------
-
-The "server" keyword supports a certain number of settings which are all passed
-as arguments on the server line. The order in which those arguments appear does
-not count, and they are all optional. Some of those settings are single words
-(booleans) while others expect one or several values after them. In this case,
-the values must immediately follow the setting name. All those settings must be
-specified after the server's address if they are used :
-
- server <name> <address>[:port] [settings ...]
-
-The currently supported settings are the following ones.
-
-addr <ipv4>
- Using the "addr" parameter, it becomes possible to use a different IP address
- to send health-checks. On some servers, it may be desirable to dedicate an IP
- address to specific component able to perform complex tests which are more
- suitable to health-checks than the application. This parameter is ignored if
- the "check" parameter is not set. See also the "port" parameter.
-
-backup
- When "backup" is present on a server line, the server is only used in load
- balancing when all other non-backup servers are unavailable. Requests coming
- with a persistence cookie referencing the server will always be served
- though. By default, only the first operational backup server is used, unless
- the "allbackups" option is set in the backend. See also the "allbackups"
- option.
-
-check
- This option enables health checks on the server. By default, a server is
- always considered available. If "check" is set, the server will receive
- periodic health checks to ensure that it is really able to serve requests.
- The default address and port to send the tests to are those of the server,
- and the default source is the same as the one defined in the backend. It is
- possible to change the address using the "addr" parameter, the port using the
- "port" parameter, the source address using the "source" address, and the
- interval and timers using the "inter", "rise" and "fall" parameters. The
- request method is define in the backend using the "httpchk", "smtpchk",
- and "ssl-hello-chk" options. Please refer to those options and parameters for
- more information.
-
-cookie <value>
- The "cookie" parameter sets the cookie value assigned to the server to
- <value>. This value will be checked in incoming requests, and the first
- operational server possessing the same value will be selected. In return, in
- cookie insertion or rewrite modes, this value will be assigned to the cookie
- sent to the client. There is nothing wrong in having several servers sharing
- the same cookie value, and it is in fact somewhat common between normal and
- backup servers. See also the "cookie" keyword in backend section.
-
-fall <count>
- The "fall" parameter states that a server will be considered as dead after
- <count> consecutive unsuccessful health checks. This value defaults to 3 if
- unspecified. See also the "check", "inter" and "rise" parameters.
-
-id <value>
- Set a persistent value for server ID. Must be unique and larger than 1000, as
- smaller values are reserved for auto-assigned ids.
-
-inter <delay>
-fastinter <delay>
-downinter <delay>
- The "inter" parameter sets the interval between two consecutive health checks
- to <delay> milliseconds. If left unspecified, the delay defaults to 2000 ms.
- It is also possible to use "fastinter" and "downinter" to optimize delays
- between checks depending on the server state :
-
- Server state | Interval used
- ---------------------------------+-----------------------------------------
- UP 100% (non-transitional) | "inter"
- ---------------------------------+-----------------------------------------
- Transitionally UP (going down), |
- Transitionally DOWN (going up), | "fastinter" if set, "inter" otherwise.
- or yet unchecked. |
- ---------------------------------+-----------------------------------------
- DOWN 100% (non-transitional) | "downinter" if set, "inter" otherwise.
- ---------------------------------+-----------------------------------------
-
- Just as with every other time-based parameter, they can be entered in any
- other explicit unit among { us, ms, s, m, h, d }. The "inter" parameter also
- serves as a timeout for health checks sent to servers if "timeout check" is
- not set. In order to reduce "resonance" effects when multiple servers are
- hosted on the same hardware, the health-checks of all servers are started
- with a small time offset between them. It is also possible to add some random
- noise in the health checks interval using the global "spread-checks"
- keyword. This makes sense for instance when a lot of backends use the same
- servers.
-
-maxconn <maxconn>
- The "maxconn" parameter specifies the maximal number of concurrent
- connections that will be sent to this server. If the number of incoming
- concurrent requests goes higher than this value, they will be queued, waiting
- for a connection to be released. This parameter is very important as it can
- save fragile servers from going down under extreme loads. If a "minconn"
- parameter is specified, the limit becomes dynamic. The default value is "0"
- which means unlimited. See also the "minconn" and "maxqueue" parameters, and
- the backend's "fullconn" keyword.
-
-maxqueue <maxqueue>
- The "maxqueue" parameter specifies the maximal number of connections which
- will wait in the queue for this server. If this limit is reached, next
- requests will be redispatched to other servers instead of indefinitely
- waiting to be served. This will break persistence but may allow people to
- quickly re-log in when the server they try to connect to is dying. The
- default value is "0" which means the queue is unlimited. See also the
- "maxconn" and "minconn" parameters.
-
-minconn <minconn>
- When the "minconn" parameter is set, the maxconn limit becomes a dynamic
- limit following the backend's load. The server will always accept at least
- <minconn> connections, never more than <maxconn>, and the limit will be on
- the ramp between both values when the backend has less than <fullconn>
- concurrent connections. This makes it possible to limit the load on the
- server during normal loads, but push it further for important loads without
- overloading the server during exceptionnal loads. See also the "maxconn"
- and "maxqueue" parameters, as well as the "fullconn" backend keyword.
-
-port <port>
- Using the "port" parameter, it becomes possible to use a different port to
- send health-checks. On some servers, it may be desirable to dedicate a port
- to a specific component able to perform complex tests which are more suitable
- to health-checks than the application. It is common to run a simple script in
- inetd for instance. This parameter is ignored if the "check" parameter is not
- set. See also the "addr" parameter.
-
-redir <prefix>
- The "redir" parameter enables the redirection mode for all GET and HEAD
- requests addressing this server. This means that instead of having HAProxy
- forward the request to the server, it will send an "HTTP 302" response with
- the "Location" header composed of this prefix immediately followed by the
- requested URI beginning at the leading '/' of the path component. That means
- that no trailing slash should be used after <prefix>. All invalid requests
- will be rejected, and all non-GET or HEAD requests will be normally served by
- the server. Note that since the response is completely forged, no header
- mangling nor cookie insertion is possible in the respose. However, cookies in
- requests are still analysed, making this solution completely usable to direct
- users to a remote location in case of local disaster. Main use consists in
- increasing bandwidth for static servers by having the clients directly
- connect to them. Note: never use a relative location here, it would cause a
- loop between the client and HAProxy!
+ hdr(Connection) -i close
- Example : server srv1 192.168.1.1:80 redir http://image1.mydomain.com check
+hdr_beg <string>
+hdr_beg(header) <string>
+ Returns true when one of the headers begins with one of the strings. See
+ "hdr" for more information on header matching.
-rise <count>
- The "rise" parameter states that a server will be considered as operational
- after <count> consecutive successful health checks. This value defaults to 2
- if unspecified. See also the "check", "inter" and "fall" parameters.
+hdr_end <string>
+hdr_end(header) <string>
+ Returns true when one of the headers ends with one of the strings. See "hdr"
+ for more information on header matching.
-slowstart <start_time_in_ms>
- The "slowstart" parameter for a server accepts a value in milliseconds which
- indicates after how long a server which has just come back up will run at
- full speed. Just as with every other time-based parameter, it can be entered
- in any other explicit unit among { us, ms, s, m, h, d }. The speed grows
- linearly from 0 to 100% during this time. The limitation applies to two
- parameters :
+hdr_sub <string>
+hdr_sub(header) <string>
+ Returns true when one of the headers contains one of the strings. See "hdr"
+ for more information on header matching.
- - maxconn: the number of connections accepted by the server will grow from 1
- to 100% of the usual dynamic limit defined by (minconn,maxconn,fullconn).
+hdr_dir <string>
+hdr_dir(header) <string>
+ Returns true when one of the headers contains one of the strings either
+ isolated or delimited by slashes. This is used to perform filename or
+ directory name matching, and may be used with Referer. See "hdr" for more
+ information on header matching.
- - weight: when the backend uses a dynamic weighted algorithm, the weight
- grows linearly from 1 to 100%. In this case, the weight is updated at every
- health-check. For this reason, it is important that the "inter" parameter
- is smaller than the "slowstart", in order to maximize the number of steps.
+hdr_dom <string>
+hdr_dom(header) <string>
+ Returns true when one of the headers contains one of the strings either
+ isolated or delimited by dots. This is used to perform domain name matching,
+ and may be used with the Host header. See "hdr" for more information on
+ header matching.
- The slowstart never applies when haproxy starts, otherwise it would cause
- trouble to running servers. It only applies when a server has been previously
- seen as failed.
+hdr_reg <regex>
+hdr_reg(header) <regex>
+ Returns true when one of the headers matches of the regular expressions. It
+ can be used at any time, but it is important to remember that regex matching
+ is slower than other methods. See also other "hdr_" criteria, as well as
+ "hdr" for more information on header matching.
-source <addr>[:<port>] [usesrc { <addr2>[:<port2>] | client | clientip } ]
-source <addr>[:<port>] [interface <name>] ...
- The "source" parameter sets the source address which will be used when
- connecting to the server. It follows the exact same parameters and principle
- as the backend "source" keyword, except that it only applies to the server
- referencing it. Please consult the "source" keyword for details.
+hdr_val <integer>
+hdr_val(header) <integer>
+ Returns true when one of the headers starts with a number which matches the
+ values or ranges specified. This may be used to limit content-length to
+ acceptable values for example. See "hdr" for more information on header
+ matching.
-track [<proxy>/]<server>
- This option enables ability to set the current state of the server by
- tracking another one. Only a server with checks enabled can be tracked
- so it is not possible for example to track a server that tracks another
- one. If <proxy> is omitted the current one is used. If disable-on-404 is
- used, it has to be enabled on both proxies.
+hdr_cnt <integer>
+hdr_cnt(header) <integer>
+ Returns true when the number of occurrence of the specified header matches
+ the values or ranges specified. It is important to remember that one header
+ line may count as several headers if it has several values. This is used to
+ detect presence, absence or abuse of a specific header, as well as to block
+ request smugling attacks by rejecting requests which contain more than one
+ of certain headers. See "hdr" for more information on header matching.
-weight <weight>
- The "weight" parameter is used to adjust the server's weight relative to
- other servers. All servers will receive a load proportional to their weight
- relative to the sum of all weights, so the higher the weight, the higher the
- load. The default weight is 1, and the maximal value is 255. If this
- parameter is used to distribute the load according to server's capacity, it
- is recommended to start with values which can both grow and shrink, for
- instance between 10 and 100 to leave enough room above and below for later
- adjustments.
+7.6. Pre-defined ACLs
+---------------------
-2.5) HTTP header manipulation
------------------------------
+Some predefined ACLs are hard-coded so that they do not have to be declared in
+every frontend which needs them. They all have their names in upper case in
+order to avoid confusion. Their equivalence is provided below. Please note that
+only the first three ones are not layer 7 based.
-In HTTP mode, it is possible to rewrite, add or delete some of the request and
-response headers based on regular expressions. It is also possible to block a
-request or a response if a particular header matches a regular expression,
-which is enough to stop most elementary protocol attacks, and to protect
-against information leak from the internal network. But there is a limitation
-to this : since HAProxy's HTTP engine does not support keep-alive, only headers
-passed during the first request of a TCP session will be seen. All subsequent
-headers will be considered data only and not analyzed. Furthermore, HAProxy
-never touches data contents, it stops analysis at the end of headers.
+ACL name Equivalent to Usage
+---------------+-----------------------------+---------------------------------
+TRUE always_true always match
+FALSE always_false never match
+LOCALHOST src 127.0.0.1/8 match connection from local host
+HTTP_1.0 req_ver 1.0 match HTTP version 1.0
+HTTP_1.1 req_ver 1.1 match HTTP version 1.1
+METH_CONNECT method CONNECT match HTTP CONNECT method
+METH_GET method GET HEAD match HTTP GET or HEAD method
+METH_HEAD method HEAD match HTTP HEAD method
+METH_OPTIONS method OPTIONS match HTTP OPTIONS method
+METH_POST method POST match HTTP POST method
+METH_TRACE method TRACE match HTTP TRACE method
+HTTP_URL_ABS url_reg ^[^/:]*:// match absolute URL with scheme
+HTTP_URL_SLASH url_beg / match URL begining with "/"
+HTTP_URL_STAR url * match URL equal to "*"
+HTTP_CONTENT hdr_val(content-length) gt 0 match an existing content-length
+REQ_CONTENT req_len gt 0 match data in the request buffer
+WAIT_END wait_end wait for end of content analysis
+---------------+-----------------------------+---------------------------------
-This section covers common usage of the following keywords, described in detail
-in section 2.2.1 :
- - reqadd <string>
- - reqallow <search>
- - reqiallow <search>
- - reqdel <search>
- - reqidel <search>
- - reqdeny <search>
- - reqideny <search>
- - reqpass <search>
- - reqipass <search>
- - reqrep <search> <replace>
- - reqirep <search> <replace>
- - reqtarpit <search>
- - reqitarpit <search>
- - rspadd <string>
- - rspdel <search>
- - rspidel <search>
- - rspdeny <search>
- - rspideny <search>
- - rsprep <search> <replace>
- - rspirep <search> <replace>
+7.7. Using ACLs to form conditions
+----------------------------------
-With all these keywords, the same conventions are used. The <search> parameter
-is a POSIX extended regular expression (regex) which supports grouping through
-parenthesis (without the backslash). Spaces and other delimiters must be
-prefixed with a backslash ('\') to avoid confusion with a field delimiter.
-Other characters may be prefixed with a backslash to change their meaning :
+Some actions are only performed upon a valid condition. A condition is a
+combination of ACLs with operators. 3 operators are supported :
- \t for a tab
- \r for a carriage return (CR)
- \n for a new line (LF)
- \ to mark a space and differentiate it from a delimiter
- \# to mark a sharp and differentiate it from a comment
- \\ to use a backslash in a regex
- \\\\ to use a backslash in the text (*2 for regex, *2 for haproxy)
- \xXX to write the ASCII hex code XX as in the C language
+ - AND (implicit)
+ - OR (explicit with the "or" keyword or the "||" operator)
+ - Negation with the exclamation mark ("!")
-The <replace> parameter contains the string to be used to replace the largest
-portion of text matching the regex. It can make use of the special characters
-above, and can reference a substring which is delimited by parenthesis in the
-regex, by writing a backslash ('\') immediately followed by one digit from 0 to
-9 indicating the group position (0 designating the entire line). This practice
-is very common to users of the "sed" program.
+A condition is formed as a disjonctive form :
-The <string> parameter represents the string which will systematically be added
-after the last header line. It can also use special character sequences above.
+ [!]acl1 [!]acl2 ... [!]acln { or [!]acl1 [!]acl2 ... [!]acln } ...
-Notes related to these keywords :
----------------------------------
- - these keywords are not always convenient to allow/deny based on header
- contents. It is strongly recommended to use ACLs with the "block" keyword
- instead, resulting in far more flexible and manageable rules.
+Such conditions are generally used after an "if" or "unless" statement,
+indicating when the condition will trigger the action.
- - lines are always considered as a whole. It is not possible to reference
- a header name only or a value only. This is important because of the way
- headers are written (notably the number of spaces after the colon).
+For instance, to block HTTP requests to the "*" URL with methods other than
+"OPTIONS", as well as POST requests without content-length, and GET or HEAD
+requests with a content-length greater than 0, and finally every request which
+is not either GET/HEAD/POST/OPTIONS !
- - the first line is always considered as a header, which makes it possible to
- rewrite or filter HTTP requests URIs or response codes, but in turn makes
- it harder to distinguish between headers and request line. The regex prefix
- ^[^\ \t]*[\ \t] matches any HTTP method followed by a space, and the prefix
- ^[^ \t:]*: matches any header name followed by a colon.
+ acl missing_cl hdr_cnt(Content-length) eq 0
+ block if HTTP_URL_STAR !METH_OPTIONS || METH_POST missing_cl
+ block if METH_GET HTTP_CONTENT
+ block unless METH_GET or METH_POST or METH_OPTIONS
- - for performances reasons, the number of characters added to a request or to
- a response is limited at build time to values between 1 and 4 kB. This
- should normally be far more than enough for most usages. If it is too short
- on occasional usages, it is possible to gain some space by removing some
- useless headers before adding new ones.
+To select a different backend for requests to static contents on the "www" site
+and to every request on the "img", "video", "download" and "ftp" hosts :
- - keywords beginning with "reqi" and "rspi" are the same as their couterpart
- without the 'i' letter except that they ignore case when matching patterns.
+ acl url_static path_beg /static /images /img /css
+ acl url_static path_end .gif .png .jpg .css .js
+ acl host_www hdr_beg(host) -i www
+ acl host_static hdr_beg(host) -i img. video. download. ftp.
- - when a request passes through a frontend then a backend, all req* rules
- from the frontend will be evaluated, then all req* rules from the backend
- will be evaluated. The reverse path is applied to responses.
+ # now use backend "static" for all static-only hosts, and for static urls
+ # of host "www". Use backend "www" for the rest.
+ use_backend static if host_static or host_www url_static
+ use_backend www if host_www
- - req* statements are applied after "block" statements, so that "block" is
- always the first one, but before "use_backend" in order to permit rewriting
- before switching.
+See section 4.2 for detailed help on the "block" and "use_backend" keywords.
-2.6) Logging
-------------
+8. Logging
+----------
One of HAProxy's strong points certainly lies is its precise logs. It probably
provides the finest level of information available for such a product, which is
@@ -4929,20 +5008,20 @@
delay.
-2.6.1) Log levels
------------------
+8.1. Log levels
+---------------
TCP and HTTP connections can be logged with informations such as date, time,
source IP address, destination address, connection duration, response times,
HTTP request, the HTTP return code, number of bytes transmitted, the conditions
in which the session ended, and even exchanged cookies values, to track a
particular user's problems for example. All messages are sent to up to two
-syslog servers. Check the "log" keyword in section 2.2 for more info about log
+syslog servers. Check the "log" keyword in section 4.2 for more info about log
facilities.
-2.6.2) Log formats
-------------------
+8.2. Log formats
+----------------
HAProxy supports 3 log formats. Several fields are common between these formats
and will be detailed in the next sections. A few of them may slightly vary with
@@ -4981,8 +5060,8 @@
backslash ('\') and the next line will start indented by two characters.
-2.6.2.1) Default log format
----------------------------
+8.2.1. Default log format
+-------------------------
This format is used when no specific option is set. The log is emitted as soon
as the connection is accepted. One should note that this currently is the only
@@ -5019,8 +5098,8 @@
will eventually disappear.
-2.6.2.2) TCP log format
------------------------
+8.2.2. TCP log format
+---------------------
The TCP format is used when "option tcplog" is specified in the frontend, and
is the recommended format for pure TCP proxies. It provides a lot of precious
@@ -5120,7 +5199,7 @@
limits have been reached. For instance, if actconn is close to 512 when
multiple connection errors occur, chances are high that the system limits
the process to use a maximum of 1024 file descriptors and that all of them
- are used. See section 1 "Global parameters" to find how to tune the system.
+ are used. See section 3 "Global parameters" to find how to tune the system.
- "feconn" is the total number of concurrent connections on the frontend when
the session was logged. It is useful to estimate the amount of resource
@@ -5182,8 +5261,8 @@
occurs.
-2.6.2.3) HTTP log format
-------------------------
+8.2.3. HTTP log format
+----------------------
The HTTP format is the most complete and the best suited for HTTP proxies. It
is enabled by when "option httplog" is specified in the frontend. It provides
@@ -5333,7 +5412,7 @@
limits have been reached. For instance, if actconn is close to 512 or 1024
when multiple connection errors occur, chances are high that the system
limits the process to use a maximum of 1024 file descriptors and that all
- of them are used. See section 1 "Global parameters" to find how to tune the
+ of them are used. See section 3 "Global parameters" to find how to tune the
system.
- "feconn" is the total number of concurrent connections on the frontend when
@@ -5423,8 +5502,8 @@
is the reason why this field must always remain the last one.
-2.6.3) Advanced logging options
--------------------------------
+8.3. Advanced logging options
+-----------------------------
Some advanced logging options are often looked for but are not easy to find out
just by looking at the various options. Here is an entry point for the few
@@ -5432,8 +5511,8 @@
for more information about their usage.
-2.6.3.1) Disabling logging of external tests
---------------------------------------------
+8.3.1. Disabling logging of external tests
+------------------------------------------
It is quite common to have some monitoring tools perform health checks on
haproxy. Sometimes it will be a layer 3 load-balancer such as LVS or any
@@ -5457,8 +5536,8 @@
only get the result of a health-check, and the request will not be logged.
-2.6.3.2) Logging before waiting for the session to terminate
-------------------------------------------------------------
+8.3.2. Logging before waiting for the session to terminate
+----------------------------------------------------------
The problem with logging at end of connection is that you have no clue about
what is happening during very long sessions, such as remote terminal sessions
@@ -5472,8 +5551,8 @@
with a '+' sign which means that real numbers are certainly larger.
-2.6.3.3) Raising log level upon errors
---------------------------------------
+8.3.3. Raising log level upon errors
+------------------------------------
Sometimes it is more convenient to separate normal traffic from errors logs,
for instance in order to ease error monitoring from log files. When the option
@@ -5486,8 +5565,8 @@
"notice" in an "admin" file, because the "err" level is higher than "notice".
-2.6.3.4) Disabling logging of successful connections
-----------------------------------------------------
+8.3.4. Disabling logging of successful connections
+--------------------------------------------------
Although this may sound strange at first, some large sites have to deal with
multiple thousands of logs per second and are experiencing difficulties keeping
@@ -5501,8 +5580,8 @@
alternative.
-2.6.4) Timing events
---------------------
+8.4. Timing events
+------------------
Timers provide a great help in troubleshooting network problems. All values are
reported in milliseconds (ms). These timers should be used in conjunction with
@@ -5620,8 +5699,8 @@
termination flags, then check the "timeout server" setting.
-2.6.5) Session state at disconnection
--------------------------------------
+8.5. Session state at disconnection
+-----------------------------------
TCP and HTTP logs provide a session termination indicator in the
"termination_state" field, just before the number of active connections. It is
@@ -5870,8 +5949,8 @@
only be solved by proper system tuning.
-2.6.6) Non-printable characters
--------------------------------
+8.6. Non-printable characters
+-----------------------------
In order not to cause trouble to log analysis tools or terminals during log
consulting, non-printable characters are not sent as-is into log files, but are
@@ -5891,16 +5970,16 @@
performed since no quote may appear anywhere else in the logs.
-2.6.7) Capturing HTTP cookies
------------------------------
+8.7. Capturing HTTP cookies
+---------------------------
Cookie capture simplifies the tracking a complete user session. This can be
achieved using the "capture cookie" statement in the frontend. Please refer to
-section 2.2 for more details. Only one cookie can be captured, and the same
+section 4.2 for more details. Only one cookie can be captured, and the same
cookie will simultaneously be checked in the request ("Cookie:" header) and in
the response ("Set-Cookie:" header). The respective values will be reported in
the HTTP logs at the "captured_request_cookie" and "captured_response_cookie"
-locations (see section 2.6.2.3 about HTTP log format). When either cookie is
+locations (see section 8.2.3 about HTTP log format). When either cookie is
not seen, a dash ('-') replaces the value. This way, it's easy to detect when a
user switches to a new session for example, because the server will reassign it
a new cookie. It is also possible to detect if a server unexpectedly sets a
@@ -5914,8 +5993,8 @@
capture cookie vgnvisitor= len 32
-2.6.8) Capturing HTTP headers
------------------------------
+8.8. Capturing HTTP headers
+---------------------------
Header captures are useful to track unique request identifiers set by an upper
proxy, virtual host names, user-agents, POST content-length, referrers, etc. In
@@ -5924,7 +6003,7 @@
Header captures are performed using the "capture request header" and "capture
response header" statements in the frontend. Please consult their definition in
-section 2.2 for more details.
+section 4.2 for more details.
It is possible to include both request headers and response headers at the same
time. Non-existant headers are logged as empty strings, and if one header
@@ -5988,8 +6067,8 @@
"GET http://www.sytadin.equipement.gouv.fr/ HTTP/1.1"
-2.6.9) Examples of logs
------------------------
+8.9. Examples of logs
+---------------------
These are real-world examples of logs accompanied with an explanation. Some of
them have been made up by hand. The syslog part has been removed for better
@@ -6055,7 +6134,7 @@
0/0 "HEAD / HTTP/1.0"
=> The request took 3s to complete (probably a network problem), and the
- connection to the server failed ('SC--') after 4 attemps of 2 seconds
+ connection to the server failed ('SC--') after 4 attempts of 2 seconds
(config says 'retries 3'), and no redispatch (otherwise we would have
seen "/+3"). Status code 503 was returned to the client. There were 115
connections on this server, 202 connections on this proxy, and 205 on
@@ -6063,7 +6142,16 @@
connection because of too many already established.
-2.7) CSV format
+9. Statistics and monitoring
+----------------------------
+
+It is possible to query HAProxy about its status. The most commonly used
+mechanism is the HTTP statistics page. This page also exposes an alternative
+CSV output format for monitoring tools. The same format is provided on the
+Unix socket.
+
+
+9.1. CSV format
---------------
The statistics may be consulted either from the unix socket or from the HTTP
@@ -6106,7 +6194,7 @@
33. rate (number of sessions per second over last elapsed second)
-2.8) Unix Socket commands
+9.2. Unix Socket commands
-------------------------
The following commands are supported on the UNIX stats socket ; all of them
@@ -6175,7 +6263,7 @@
00204+ minal\r\n
00211 \r\n
- In the example above, we know that the backend "http-in" which has internal
+ In the example above, we see that the backend "http-in" which has internal
ID 2 has blocked an invalid response from its server s2 which has internal
ID 1. The request was on session 54 initiated by source 127.0.0.1 and
received by frontend fe-eth0 whose ID is 1. The total response length was