doc/configuration.txt

                         ----------------------
                                 HAProxy
                          Configuration Manual
                         ----------------------
                             version 1.3.13
                             willy tarreau
                               2007/10/15


This document covers the configuration language as implemented in the version
specified above. It does not provide any hint, example or advice. For such
docuemntation, please refer to the Reference Manual or the Architecture Manual.


HAProxy's configuration process involves 3 major sources of parameters :

  - the arguments from the command-line, which always take precedence
  - the "global" section, which sets process-wide parameters
  - the proxies sections which can take form of "defaults", "listen",
    "frontend" and "backend".

1. Global parameters
--------------------

Parameters in the "global" section are process-wide and often OS-specific. They
are generally set once for all and do not need being changed once correct. Some
of them have command-line equivalents.

The following keywords are supported in the "global" section :

 * Process management and security
   - chroot
   - daemon
   - gid
   - group
   - log
   - nbproc
   - pidfile
   - uid
   - ulimit-n
   - user
  
 * Performance tuning
   - maxconn
   - noepoll
   - nokqueue
   - nopoll
   - nosepoll
   - tune.maxpollevents
   - spread-checks
  
 * Debugging
   - debug
   - quiet
   - stats


1.1) Process management and security
------------------------------------

chroot <jail dir>
  Changes current directory to <jail dir> and performs a chroot() there before
  dropping privileges. This increases the security level in case an unknown
  vulnerability would be exploited, since it would make it very hard for the
  attacker to exploit the system. This only works when the process is started
  with superuser privileges. It is important to ensure that <jail_dir> is both
  empty and unwritable to anyone.
  
daemon
  Makes the process fork into background. This is the recommended mode of
  operation. It is equivalent to the command line "-D" argument. It can be
  disabled by the command line "-db" argument.

gid <number>
  Changes the process' group ID to <number>. It is recommended that the group
  ID is dedicated to HAProxy or to a small set of similar daemons. HAProxy must
  be started with a user belonging to this group, or with superuser privileges.
  See also "group" and "uid".
  
group <group name>
  Similar to "gid" but uses the GID of group name <group name> from /etc/group.
  See also "gid" and "user".
  
log <address> <facility> [max level]
  Adds a global syslog server. Up to two global servers can be defined. They
  will receive logs for startups and exits, as well as all logs from proxies
  configured with "log global". <address> is an IPv4 address optionally
  followed by a colon and an UDP port. If no port is specified, 514 is used
  by default (the standard syslog port). <facility> must be one of the 24
  standard syslog facilities :

          kern   user   mail   daemon auth   syslog lpr    news
          uucp   cron   auth2  ftp    ntp    audit  alert  cron2
          local0 local1 local2 local3 local4 local5 local6 local7

  An optional level can be specified to filter outgoing messages. By default,
  all messages are sent. If a level is specified, only messages with a severity
  at least as important as this level will be sent. 8 levels are known :

	  emerg  alert  crit   err    warning notice info  debug

nbproc <number>
  Creates <number> processes when going daemon. This requires the "daemon"
  mode. By default, only one process is created, which is the recommended mode
  of operation. For systems limited to small sets of file descriptors per
  process, it may be needed to fork multiple daemons. USING MULTIPLE PROCESSES
  IS HARDER TO DEBUG AND IS REALLY DISCOURAGED. See also "daemon".

pidfile <pidfile>
  Writes pids of all daemons into file <pidfile>. This option is equivalent to
  the "-p" command line argument. The file must be accessible to the user
  starting the process. See also "daemon".

uid <number>
  Changes the process' user ID to <number>. It is recommended that the user ID
  is dedicated to HAProxy or to a small set of similar daemons. HAProxy must
  be started with superuser privileges in order to be able to switch to another
  one. See also "gid" and "user".

ulimit-n <number>
  Sets the maximum number of per-process file-descriptors to <number>. By
  default, it is automatically computed, so it is recommended not to use this
  option.

user <user name>
  Similar to "uid" but uses the UID of user name <user name> from /etc/passwd.
  See also "uid" and "group".


1.2) Performance tuning
-----------------------

maxconn <number>
  Sets the maximum per-process number of concurrent connections to <number>. It
  is equivalent to the command-line argument "-n". Proxies will stop accepting
  connections when this limit is reached. The "ulimit-n" parameter is
  automatically adjusted according to this value. See also "ulimit-n".

noepoll
  Disables the use of the "epoll" event polling system on Linux. It is
  equivalent to the command-line argument "-de". The next polling system
  used will generally be "poll". See also "nosepoll", and "nopoll".

nokqueue
  Disables the use of the "kqueue" event polling system on BSD. It is
  equivalent to the command-line argument "-dk". The next polling system
  used will generally be "poll". See also "nopoll".

nopoll
  Disables the use of the "poll" event polling system. It is equivalent to the
  command-line argument "-dp". The next polling system used will be "select".
  It should never be needed to didsable "poll" since it's available on all
  platforms supported by HAProxy. See also "nosepoll", and "nopoll" and
  "nokqueue".

nosepoll
  Disables the use of the "speculative epoll" event polling system on Linux. It
  is equivalent to the command-line argument "-ds". The next polling system
  used will generally be "epoll". See also "nosepoll", and "nopoll".

tune.maxpollevents <number>
  Sets the maximum amount of events that can be processed at once in a call to
  the polling system. The default value is adapted to the operating system. It
  has been noticed that reducing it below 200 tends to slightly decrease
  latency at the expense of network bandwidth, and increasing it above 200
  tends to trade latency for slightly increased bandwidth.

spread-checks <0..50, in percent>
  Sometimes it is desirable to avoid sending health checks to servers at exact
  intervals, for instance when many logical servers are located on the same
  physical server. With the help of this parameter, it becomes possible to add
  some randomness in the check interval between 0 and +/- 50%. A value between
  2 and 5 seems to show good results. The default value remains at 0.


1.3) Debugging
---------------

debug
  Enables debug mode which dumps to stdout all exchanges, and disables forking
  into background. It is the equivalent of the command-line argument "-d". It
  should never be used in a production configuration since it may prevent full
  system startup.

quiet
  Do not display any message during startup. It is equivalent to the command-
  line argument "-q".

stats
  Dump internal statistics to stdout at regular interval. It is available for
  development purposes only and should never be set.


2) Proxies
----------
Proxy configuration can be located in a set of sections :
 - defaults <name>
 - frontend <name>
 - backend  <name>
 - listen   <name>

A "defaults" section sets default parameters for all other sections following
its declaration. Those default parameters are reset by the next "defaults"
section. See below for the list of parameters which can be set in a "defaults"
section.

A "frontend" section describes a set of listening sockets accepting client
connections.

A "backend" section describes a set of servers to which the proxy will connect
to forward incoming connections.

A "listen" section defines a complete proxy with its frontend and backend
parts combined in one section. It is generally useful for TCP-only traffic.

The following list of keywords is supported. Most of them may only be used in a
limited set of section types.

keyword                 defaults   frontend   listen    backend
----------------------+----------+----------+---------+---------
acl                         -          X         X         X   
appsession                  -          -         X         X   
balance                     -          -         X         X   
bind                        -          X         X         -   
block                       -          X         X         X
capture cookie              X          X         X         X
capture request header      X          X         X         X
capture response header     X          X         X         X
clitimeout                  X          X         X         -
contimeout                  X          X         X         X
cookie                      X          -         X         X
default_backend             -          X         X         -
disabled                    -          X         X         X
dispatch                    -          -         X         X
enabled                     -          X         X         X
errorfile                   X          X         X         X
errorloc                    X          X         X         X
errorloc302                 X          X         X         X
errorloc303                 X          X         X         X
fullconn                    X          -         X         X
grace                       -          X         X         X
log                         X          X         X         X
maxconn                     X          X         X         -
mode                        X          X         X         X
monitor-net                 X          X         X         -
monitor-uri                 X          X         X         -
option abortonclose         X          -         X         X
option allbackups           X          -         X         X
option checkcache           X          -         X         X
option clitcpka             X          X         X         -
option dontlognull          X          X         X         -
option forceclose           X          -         X         X
option forwardfor           X          X         X         X
option httpchk              X          -         X         X
option httpclose            X          X         X         X
option httplog              X          X         X         X
option logasap              X          X         X         -
option nolinger             X          X         X         X
option persist              X          -         X         X
option redispatch           X          -         X         X
option smtpchk              X          -         X         X
option srvtcpka             X          -         X         X
option ssl-hello-chk        X          -         X         X
option tcpka                X          X         X         X
option tcplog               X          X         X         X
option tcpsplice            X          X         X         X
option transparent          X          X         X         -
redisp                      X          -         X         X
redispatch                  X          -         X         X
reqadd                      -          X         X         X
reqallow                    -          X         X         X
reqdel                      -          X         X         X
reqdeny                     -          X         X         X
reqiallow                   -          X         X         X
reqidel                     -          X         X         X
reqideny                    -          X         X         X
reqipass                    -          X         X         X
reqirep                     -          X         X         X
reqisetbe                   -          X         X         X
reqitarpit                  -          X         X         X
reqpass                     -          X         X         X
reqrep                      -          X         X         X
reqsetbe                    -          X         X         X
reqtarpit                   -          X         X         X
retries                     X          -         X         X
rspadd                      -          X         X         X
rspdel                      -          X         X         X
rspdeny                     -          X         X         X
rspidel                     -          X         X         X
rspideny                    -          X         X         X
rspirep                     -          X         X         X
rsprep                      -          X         X         X
server                      -          -         X         X
source                      X          -         X         X
srvtimeout                  X          -         X         X
stats auth                  X          -         X         X
stats enable                X          -         X         X
stats realm                 X          -         X         X
stats refresh               X          -         X         X
stats scope                 X          -         X         X
stats uri                   X          -         X         X
stats hide-version          X          -         X         X
transparent                 X          X         X         -
use_backend                 -          X         X         -
usesrc                      X          -         X         X
----------------------+----------+----------+---------+---------
keyword                 defaults   frontend   listen    backend


2.1) using ACLs
---------------

The use of Access Control Lists (ACL) provides a flexible solution to perform
content switching. 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 an ACL <aclname> or completes an existing one with new
tests. Those tests apply to the portion of request 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.

There is no limit to the number of ACLs. The unused ones do not affect
performance, they just consume a small amount of memory.

The current 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 :
  - integers or integer ranges
  - strings
  - regular expressions
  - IP addresses and networks


2.1.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
expressed with a lower and an upper bound separated with a colon, both of which
may be omitted.

For instance, "1024:65535" is a valid range to represent a range of
unprivileged ports, and "1024:" would also work. "0:1023" is a valid
representation of privileged ports, and ":1023" would also work.

For an easier usage, comparison operators are also supported. Note that using
operators with ranges does not make much sense and is discouraged. Also, it
does not make much sense to perform order comparisons with a set of values.

Available operators are :

  eq : true if the tested value equals at least one value
  ge : true if the tested value is greater than or equal to at least one value
  gt : true if the tested value is greater than at least one value
  le : true if the tested value is less than or equal to at least one value
  lt : true if the tested value is less than at least one value

For instance, the following ACL matches negative Content-Length headers :

  acl negative-length hdr_val(content-length) lt 0


2.1.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
characters such as the space. If the "-i" flag is passed before the first
string, then the matching will be performed ignoring the case. In order
to match the string "-i", either set it second, or pass the "--" flag
before the first string.


2.1.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
possible to escape some characters such as the space. If the "-i" flag is
passed before the first regex, then the matching will be performed ignoring
the case. In order to match the string "-i", either set it second, or pass
the "--" flag before the first string.


2.1.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
within the network. Plain addresses may also be replaced with a resolvable
host name, but this practise is generally discouraged as it makes it more
difficult to read configurations.


2.1.5) Available matching criteria
----------------------------------

always_false
  This one never matches. All values and flags are ignored. It may be used as
  a temporary replacement for another one when adjusting configurations.

always_true
  This one always matches. All values and flags are ignored. It may be used as
  a temporary replacement for another one when adjusting configurations.

src <ip_address>
  Applies to the client's IP address. It is usually used to limit access to
  certain resources such as statistics. Note that it is the TCP-level source
  address which is used, and not the address of a client behind a proxy.

src_port <integer>
  Applies to the client's TCP source port. This has a very limited usage.

dst <ip_address>
  Applies to the local IP address the client connected to. It can be used to
  switch to a different backend for some alternative addresses.

dst_port <integer>
  Applies to the local port the client connected to. It can be used to switch
  to a different backend for some alternative ports.

dst_conn <integer>
  Applies to the number of currently established connections on the frontend,
  including the one being evaluated. It can be used to either return a sorry
  page before hard-blocking, or to use a specific backend to drain the requests
  when the farm is considered saturated.

method <string>
  Applies to the method in the HTTP request, eg: "GET". Some predefined ACL
  already check for most common methods.

req_ver <string>
  Applies to the version string in the HTTP request, eg: "1.0". Some predefined
  ACL already check for versions 1.0 and 1.1.

path <string>
  Returns true when the path part of the request, which starts at the first
  slash and ends before the question mark, equals one of the strings. It may be
  used to match known files, such as /favicon.ico.

path_beg <string>
  Returns true when the path begins with one of the strings. This can be used to
  send certain directory names to alternative backends.

path_end <string>
  Returns true when the path ends with one of the strings. This may be used to
  control file name extension.

path_sub <string>
  Returns true when the path contains one of the strings. It can be used to
  detect particular patterns in paths, such as "../" for example. See also
  "path_dir".

path_dir <string>
  Returns true when one of the strings is found isolated or delimited with
  slashes in the path. This is used to perform filename or directory name
  matching without the risk of wrong match due to colliding prefixes. See also
  "url_dir" and "path_sub".

path_dom <string>
  Returns true when one of the strings is found isolated or delimited with dots
  in the path. This may be used to perform domain name matching in proxy
  requests. See also "path_sub" and "url_dom".

path_reg <regex>
  Returns true when the path matches one of the regular expressions. It can be
  used any time, but it is important to remember that regex matching is slower
  than other methods. See also "url_reg" and all "path_" criteria.

url <string>
  Applies to the whole URL passed in the request. The only real use is to match
  "*", for which there already is a predefined ACL.

url_beg <string>
  Returns true when the URL begins with one of the strings. This can be used to
  check whether a URL begins with a slash or with a protocol scheme.

url_end <string>
  Returns true when the URL ends with one of the strings. It has very limited
  use. "path_end" should be used instead for filename matching.

url_sub <string>
  Returns true when the URL contains one of the strings. It can be used to
  detect particular patterns in query strings for example. See also "path_sub".

url_dir <string>
  Returns true when one of the strings is found isolated or delimited with
  slashes in the URL. This is used to perform filename or directory name
  matching without the risk of wrong match due to colliding prefixes. See also
  "path_dir" and "url_sub".

url_dom <string>
  Returns true when one of the strings is found isolated or delimited with dots
  in the URL. This is used to perform domain name matching without the risk of
  wrong match due to colliding prefixes. See also "url_sub".

url_reg <regex>
  Returns true when the URL matches one of the regular expressions. It can be
  used any time, but it is important to remember that regex matching is slower
  than other methods. See also "path_reg" and all "url_" criteria.

hdr <string> 
hdr(header) <string>
  Note: all the "hdr*" matching criteria either apply to all headers, or to a
  particular header whose name is passed between parenthesis and without any
  space. The header matching complies with RFC2616, and treats as separate
  headers all values delimited by comas.

  The "hdr" criteria returns true if any of the headers matching the criteria
  match any of the strings. This can be used to check exact 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 count of the headers which matches the values or ranges
  specified. This is used to detect presence or absence 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.1.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 :

ACL name          Equivalent to                Usage
---------------+-----------------------------+---------------------------------
TRUE             always_true  1                always match
FALSE            always_false 0                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
---------------+-----------------------------+---------------------------------


2.1.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/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 below for the detailed help on the "block" and "use_backend" keywords.