--- /data/web/w.ods.org/tools/haproxy/doc/haproxy-en.txt	Sat Apr 30 20:09:00 2005
+++ doc/haproxy-en.txt	Sun Aug  7 13:33:55 2005
@@ -2,9 +2,9 @@
                              H A - P r o x y
                             Reference  Manual
                            -------------------
-         		      version 1.1.31
+                              version 1.1.32
 			      willy tarreau
-			        2005/04/24
+                                2005/08/07
 
 ============
 | Abstract |
@@ -100,6 +100,8 @@
   - debug
   - quiet
   - pidfile <file>
+  - ulimit-n <number>
 
 1.1) Event logging
 ------------------
@@ -133,14 +135,15 @@
 	log 192.168.2.200 local3
 	log 127.0.0.1     local4 notice
 
 1.2) limiting the number of connections
 ---------------------------------------
 It is possible and recommended to limit the global number of per-process
-connections. Since one connection includes both a client and a server, it
-means that the max number of TCP sessions will be about the double of this
-number. It's important to understand this when trying to find best values
-for 'ulimit -n' before starting the proxy. To anticipate the number of
-sockets needed, all these parameters must be counted :
+connections using the 'maxconn' global keyword. Since one connection includes
+both a client and a server, it means that the max number of TCP sessions will
+be about the double of this number. It's important to understand this when
+trying to find best values for 'ulimit -n' before starting the proxy. To
+anticipate the number of sockets needed, all these parameters must be counted :
 
   - 1 socket per incoming connection
   - 1 socket per outgoing connection
@@ -150,8 +153,18 @@
 
 In simple configurations where each proxy only listens one one address/port,
 set the limit of file descriptors (ulimit -n) to 
-(2 * maxconn + nbproxies + nbservers + 1). In a future release, haproxy may
-be able to set this value itself.
+(2 * maxconn + nbproxies + nbservers + 1). Starting with versions 1.1.32/1.2.6,
+it is now possible to set the limit in the configuration using the 'ulimit-n'
+global keyword, provided the proxy is started as root. This puts an end to the
+recurrent problem of ensuring that the system limits are adapted to the proxy
+values. Note that these limits are per-process.
+Example :
+---------
+    global
+        maxconn 32000
+        ulimit-n 65536
 
 1.3) Drop of priviledges
 ------------------------
@@ -198,6 +211,7 @@
 	gid	30000
 	chroot  /var/chroot/haproxy
 
 1.4) Startup modes
 ------------------
 The service can start in several different :
@@ -221,6 +235,7 @@
 ways. This mode is incompatible with 'daemon' and 'quiet' modes for obvious
 reasons.
 
 1.5) Increasing the overall processing power
 --------------------------------------------
 On multi-processor systems, it may seem to be a shame to use only one processor,
@@ -316,6 +331,7 @@
         bind :80,:443
 	bind 10.0.0.1:10080,10.0.0.1:10443
 
 2.1) Inhibiting a service
 -------------------------
 A service may be disabled for maintenance reasons, without needing to comment
@@ -328,6 +344,7 @@
 Note: the 'enabled' keyword allows to enable a service which has been disabled
       previously by a default configuration.
 
 2.2) Modes of operation
 -----------------------
 A service can work in 3 different distinct modes :
@@ -380,6 +397,38 @@
 	mode health
 	option httpchk
 
+Monitoring
+----------
+Versions 1.1.32 and 1.2.6 provide a new solution to check the proxy's
+availability without perturbating the service. The 'monitor-net' keyword was
+created to specify a network of equipments which CANNOT use the service for
+anything but health-checks. This is particularly suited to TCP proxies, because
+it prevents the proxy from relaying the monitor's connection to the remote
+server.
+When used with TCP, the connection is accepted then closed and nothing is
+logged. This is enough for a front-end load-balancer to detect the service as
+available.
+When used with HTTP, the connection is accepted, nothing is logged, the
+following response is sent, then the session is closed : "HTTP/1.0 200 OK".
+This is normally enough for any front-end HTTP load-balancer to detect the
+service as available too, both with TCP and HTTP checks.
+Proxies using the "monitor-net" keyword can remove the "option dontlognull", as
+it will make them log empty connections from hosts outside the monitoring
+network.
+Example :
+---------
+    listen tse-proxy
+       bind :3389,:1494,:5900  # TSE, ICA and VNC at once.
+       mode tcp
+       balance roundrobin
+       server tse-farm 192.168.1.10
+       monitor-net 192.168.1.252/31   # L4 load-balancers on .252 and .253
 
 2.3) Limiting the number of simultaneous connections
 ----------------------------------------------------
@@ -458,6 +507,7 @@
     compensate for a packet loss. A 4 seconds time-out seems a reasonable
     minimum which will considerably reduce connection failures.
 
 2.6) Attempts to reconnect
 --------------------------
 After a connection failure to a server, it is possible to retry, potentially
@@ -696,7 +746,6 @@
 
 3.1) Server monitoring
 ----------------------
 It is possible to check the servers status by trying to establish TCP
 connections or even sending HTTP requests to them. A server which fails to
 reply to health checks as expected will not be used by the load balancing
@@ -836,7 +885,7 @@
 	server web-backup 192.168.2.1:80 cookie server03 check backup
 	server web-excuse 192.168.3.1:80 check backup
 
-# SMTP+TLS relaying with heakth-checks and backup servers
+# SMTP+TLS relaying with health-checks and backup servers
 
     listen http_proxy :25,:587
 	mode tcp
@@ -886,6 +935,7 @@
 Other features are available. They are transparent mode, event logging and
 header rewriting/filtering.
 
 4.1) Network features
 ---------------------
 4.1.1) Transparent mode
@@ -974,6 +1024,32 @@
 
 4.2) Event logging
 ------------------
+HAProxy's strength certainly lies in its precise logs. It probably provides the
+finest level of information available for such a product, which is very
+important for troubleshooting complex environments. Standard log information
+include client ports, TCP/HTTP state timers, precise session state at
+termination and precise termination cause, information about decisions to
+direct trafic to a server, and of course the ability to capture arbitrary
+headers.
+In order to improve administrators reactivity, it offers a great transparency
+about encountered problems, both internal and external, and it is possible to
+send logs to different sources at the same time with different level filters :
+  - global process-level logs (system errors, start/stop, etc..)
+  - per-listener system and internal errors (lack of resource, bugs, ...)
+  - per-listener external troubles (servers up/down, max connections)
+  - per-listener activity (client connections), either at the establishment or
+    at the termination.
+The ability to distribute different levels of logs to different log servers
+allow several production teams to interact and to fix their problems as soon
+as possible. For example, the system team might monitor system-wide errors,
+while the application team might be monitoring the up/down for their servers in
+real time, and the security team might analyze the activity logs with one hour
+delay.
 4.2.1) Log levels
 -----------------
 TCP and HTTP connections can be logged with informations such as date, time,
@@ -1009,14 +1085,27 @@
 containing more information such as session duration and its state during the
 disconnection.
 
-Example :
----------
+Example of TCP logging :
+------------------------
     listen relais-tcp 0.0.0.0:8000
 	mode tcp
 	option tcplog
 	log 192.168.2.200 local3
 
->>> haproxy[18989]: 127.0.0.1:34550 [15/Oct/2003:15:24:28] relais-tcp Srv1 0/5007 0 --
+>>> haproxy[18989]: 127.0.0.1:34550 [15/Oct/2003:15:24:28] relais-tcp Srv1 0/5007 0 -- 1/1
+  
+    Field  Format                                Example
+      
+        1  process_name '[' pid ']:'             haproxy[18989]:
+        2  client_ip ':' client_port             127.0.0.1:34550
+        3  '[' date ']'                          [15/Oct/2003:15:24:28]
+        4  listener_name                         relais-tcp
+        5  server_name                           Srv1
+        6  connect_time '/' total_time           0/5007
+        7  bytes_read                            0
+        8  termination_state                     --
+        9  listener_conns '/' process_conns      1/1
 
 Another option, 'httplog', provides more detailed information about HTTP
 contents, such as the request and some cookies. In the event where an external
@@ -1025,15 +1114,39 @@
 transfer any data, by the setting of the 'dontlognull' option. This only has
 effect on sessions which are established then closed.
 
-Example :
----------
+Example of HTTP logging :
+-------------------------
     listen http_proxy 0.0.0.0:80
 	mode http
 	option httplog
 	option dontlognull
 	log 192.168.2.200 local3
 
->>> haproxy[674]: 127.0.0.1:33319 [15/Oct/2003:08:31:57] relais-http Srv1 9/7/147/723 200 243 - - ---- "HEAD / HTTP/1.0"
+>>> haproxy[674]: 127.0.0.1:33319 [15/Oct/2003:08:31:57] relais-http Srv1 9/7/147/723 200 243 - - ---- 3/3 "HEAD / HTTP/1.0"
+More complete example
+    haproxy[18989]: 10.0.0.1:34552 [15/Oct/2003:15:26:31] relais-http Srv1 3183/-1/-1/11215 503 0 - - SC-- 202/205 {w.ods.org|Mozilla} {} "HEAD / HTTP/1.0" 
+    Field  Format                                Example
+  
+        1  process_name  '[' pid ']:'            haproxy[18989]:
+        2  client_ip ':' client_port             10.0.0.1:34552
+        3  '[' date ']'                          [15/Oct/2003:15:26:31]
+        4  listener_name                         relais-http
+        5  server_name                           Srv1
+        6  Tq '/' Tc '/' Tr '/' Tt               3183/-1/-1/11215
+        7  HTTP_return_code                      503
+        8  bytes_read                            0
+        9  captured_request_cookie               -
+       10  captured_response_cookie              -
+       11  termination_state                     SC--
+       12  listener_conns '/' process_conns      202/205
+       13  '{' captured_request_headers '}'      {w.ods.org|Mozilla}
+       14  '{' captured_response_headers '}'     {}
+       15  '"' HTTP_request '"'                  "HEAD / HTTP/1.0"
+  
+Note for log parsers: the URI is ALWAYS the end of the line starting with the
+                      first double quote '"'.
 
 The problem when logging at end of connection is that you have no clue about
 what is happening during very long sessions. To workaround this problem, a
@@ -1058,8 +1171,7 @@
 	option logasap
 	log 192.168.2.200 local3
 
->>> haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/7/14/+30 200 +243 - - ---- "GET /image.iso HTTP/1.0"
+>>> haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/7/14/+30 200 +243 - - ---- 3/3 "GET /image.iso HTTP/1.0"
 
 4.2.3) Timing events
 --------------------
@@ -1128,61 +1240,177 @@
 
 4.2.4) Session state at disconnection
 -------------------------------------
-TCP and HTTP logs provide a session completion indicator. It's a 4-characters
-(2 in TCP) field preceeding the HTTP request, and indicating :
+TCP and HTTP logs provide a session completion indicator in the
+<termination_state> field, just before the number of active
+connections. It is 2-characters long in TCP, and 4-characters long in
+HTTP, each of which has a special meaning :
   - On the first character, a code reporting the first event which caused the
     session to terminate :
 
-        C : the TCP session was aborted by the client.
-	S : the TCP session was aborted by the server, or the server refused it.
-	P : the session was abordted prematurely by the proxy, either because of
-	    an internal error, because a DENY filter was matched, or because of
-	    a security check which detected a dangerous error in server
-	    response.
-	c : the client time-out expired first.
-	s : the server time-out expired first.
+        C : the TCP session was unexpectedly aborted by the client.
+        S : the TCP session was unexpectedly aborted by the server, or the
+            server explicitly refused it.
+        P : the session was prematurely aborted by the proxy, because of a
+            connection limit enforcement, because a DENY filter was matched,
+            or because of a security check which detected and blocked a
+            dangerous error in server response which might have caused
+            information leak (eg: cacheable cookie).
+        R : a resource on the proxy has been exhausted (memory, sockets, source
+            ports, ...). Usually, this appears during the connection phase, and
+            system logs should contain a copy of the precise error.
+        I : an internal error was identified by the proxy during a self-check.
+            This should NEVER happen, and you are encouraged to report any log
+            containing this, because this is a bug.
+        c : the client-side time-out expired first.
+        s : the server-side time-out expired first.
 	- : normal session completion.
 
-  - on the second character, the HTTP session state when it was closed :
+  - on the second character, the TCP/HTTP session state when it was closed :
+        R : waiting for complete REQUEST from the client (HTTP only). Nothing
+            was sent to any server.
+        C : waiting for CONNECTION to establish on the server. The server might
+            at most have noticed a connection attempt.
+        H : waiting for, receiving and processing server HEADERS (HTTP only).
+        D : the session was in the DATA phase.
 
-        R : waiting for complete REQUEST from the client
-	C : waiting for CONNECTION to establish on the server
-	H : processing server HEADERS
-	D : the session was in the DATA phase
 	L : the proxy was still transmitting LAST data to the client while the
 	    server had already finished.
 	- : normal session completion after end of data transfer.
 
   - the third character tells whether the persistence cookie was provided by
     the client (only in HTTP mode) :
 
-        N : the client provided NO cookie.
-	I : the client provided an INVALID cookie matching no known server.
+        N : the client provided NO cookie. This is usually the case on new
+            connections.
+        I : the client provided an INVALID cookie matching no known
+            server. This might be caused by a recent configuration change,
+            mixed cookies between HTTP/HTTPS sites, or an attack.
 	D : the client provided a cookie designating a server which was DOWN,
 	    so either the 'persist' option was used and the client was sent to
 	    this server, or it was not set and the client was redispatched to
 	    another server.
 	V : the client provided a valid cookie, and was sent to the associated
 	    server.
 	- : does not apply (no cookie set in configuration).
 
   - the last character reports what operations were performed on the persistence
     cookie returned by the server (only in HTTP mode) :
 
-        N : NO cookie was provided by the server.
+        N : NO cookie was provided by the server, and none was inserted either.
+        I : no cookie was provided by the server, and the proxy INSERTED one.
         P : a cookie was PROVIDED by the server and transmitted as-is.
-	I : no cookie was provided by the server, and one was INSERTED by the
-	    proxy.
-	D : the cookie provided by the server was DELETED by the proxy.
 	R : the cookie provided by the server was REWRITTEN by the proxy.
+        D : the cookie provided by the server was DELETED by the proxy.
 	- : does not apply (no cookie set in configuration).
 
-The 'capture' keyword allows to capture and log informations exchanged between
-clients and servers. As of version 1.1.23, only cookies can be captured, which
-makes it easy to track a complete user session. The syntax is :
+The combination of the two first flags give a lot of information about what was
+happening when the session terminated. It can be helpful to detect server
+saturation, network troubles, local system resource starvation, attacks, etc...
+The most common termination flags combinations are indicated here.
+   Flags  Reason
+      CR  The client aborted before sending a full request. Most probably the
+          request was done by hand using a telnet client, and aborted early.
+      cR  The client timed out before sending a full request. This is sometimes
+          caused by too large TCP MSS values on the client side for PPPoE
+          networks which cannot transport full-sized packets, or by clients
+          sending requests by hand and not typing fast enough.
+      SC  The server explicitly refused the connection (the proxy received a
+          TCP RST or an ICMP in return). Under some circumstances, it can
+          also be the network stack telling the proxy that the server is
+          unreachable (eg: no route, or no ARP response on local network).
+      sC  The connection to the server did not complete during contimeout.
+      PC  The proxy refused to establish a connection to the server because the
+          maxconn limit has been reached. The listener's maxconn parameter may
+          be increased in the proxy configuration, as well as the global
+          maxconn parameter.
+      RC  A local resource has been exhausted (memory, sockets, source ports)
+          preventing the connection to the server from establishing. The error
+          logs will tell precisely what was missing. Anyway, this can only be
+          solved by system tuning.
+      cH  The client timed out during a POST request. This is sometimes caused
+          by too large TCP MSS values for PPPoE networks which cannot transport
+          full-sized packets.
+      SH  The server aborted before sending its full headers, or it crashed.
+      sH  The server failed to reply during the srvtimeout delay, which
+          indicates too long transactions, probably caused by back-end
+          saturation. The only solutions are to fix the problem on the
+          application or to increase the 'srvtimeout' parameter to support
+          longer delays (at the risk of the client giving up anyway).
+      
+      PR  The proxy blocked the client's request, either because of an invalid
+          HTTP syntax, in which case it returned an HTTP 400 error to the
+          client, or because a deny filter matched, in which case it returned
+          an HTTP 403 error.
+      PH  The proxy blocked the server's response, because it was invalid,
+          incomplete, dangerous (cache control), or matched a security filter.
+          In any case, an HTTP 502 error is sent to the client.
+      cD  The client did not read any data for as long as the clitimeout delay.
+          This is often caused by network failures on the client side.
+      CD  The client unexpectedly aborted during data transfer. This is either
+          caused by a browser crash, or by a keep-alive session between the
+          server and the client terminated first by the client.
+      sD  The server did nothing during the srvtimeout delay. This is often
+          caused by too short timeouts on L4 equipements before the server
+          (firewalls, load-balancers, ...).
+4.2.5) Non-printable characters
+-------------------------------
+As of version 1.1.29, non-printable characters are not sent as-is into log
+files, but are converted to their two-digits hexadecimal representation,
+prefixed by the character '#'. The only characters that can now be logged
+without being escaped are between 32 and 126 (inclusive). Obviously, the
+escape character '#' is also encoded to avoid any ambiguity. It is the same for
+the character '"', as well as '{', '|' and '}' when logging headers.
+4.2.6) Capturing HTTP headers and cookies
+-----------------------------------------
+Version 1.1.23 brought cookie capture, and 1.1.29 the header capture. All this
+is performed using the 'capture' keyword.
+Cookie capture makes it easy to track a complete user session. The syntax is :
 
     capture cookie <cookie_prefix> len <capture_length>
 
+This will enable cookie capture from both requests and responses. 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.
 The FIRST cookie whose name starts with <cookie_prefix> will be captured, and
 logged as 'NAME=value', without exceeding <capture_length> characters (64 max).
 When the cookie name is fixed and known, it's preferable to suffix '=' to it to
@@ -1198,63 +1426,16 @@
 
 In the logs, the field preceeding the completion indicator contains the cookie
 value as sent by the server, preceeded by the cookie value as sent by the
-client. Each of these field is replaced with '-' when no cookie was seen.
-4.2.5) Examples of logs
------------------------
-- haproxy[674]: 127.0.0.1:33319 [15/Oct/2003:08:31:57] relais-http Srv1 6559/7/147/6723 200 243 - - ---- "HEAD / HTTP/1.0"
-  => long request (6.5s) entered by hand through 'telnet'. The server replied
-     in 147 ms, and the session ended normally ('----')
-- haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/7/14/+30 200 +243 - - ---- "GET /image.iso HTTP/1.0"
-  => request for a long data transfer. The 'logasap' option was specified, so
-     the log was produced just before transfering data. The server replied in
-     14 ms, 243 bytes of headers were sent to the client, and total time from
-     accept to first data byte is 30 ms.
-- haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/7/14/30 502 243 - - PH-- "GET /cgi-bin/bug.cgi? HTTP/1.0"
-  => the proxy blocked a server response either because of an 'rspdeny' or
-     'rspideny' filter, or because it blocked sensible information which risked
-     being cached. In this case, the response is replaced with a '502 bad
-     gateway'.
-- haproxy[18113]: 127.0.0.1:34548 [15/Oct/2003:15:18:55] relais-http <NOSRV> -1/-1/-1/8490 -1 0 - - CR-- "" 
-  => the client never completed its request and aborted itself ('C---') after
-     8.5s, while the proxy was waiting for the request headers ('-R--').
-     Nothing was sent to the server.
-- haproxy[18113]: 127.0.0.1:34549 [15/Oct/2003:15:19:06] relais-http <NOSRV> -1/-1/-1/50001 408 0 - - cR-- "" 
-  => The client never completed its request, which was aborted by the time-out
-     ('c---') after 50s, while the proxy was waiting for the request headers ('-R--').
-     Nothing was sent to the server, but the proxy could send a 408 return code
-     to the client.
-- haproxy[18989]: 127.0.0.1:34550 [15/Oct/2003:15:24:28] relais-tcp Srv1 0/5007 0 cD 
-  => This is a 'tcplog' entry. Client-side time-out ('c----') occured after 5s.
-- haproxy[18989]: 10.0.0.1:34552 [15/Oct/2003:15:26:31] relais-http Srv1 3183/-1/-1/11215 503 0 - - SC-- "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
-     (config says 'retries 3'), then a 503 error code was sent to the client.
-4.2.6) Non-printable characters
--------------------------------
-As of version 1.1.29, non-printable characters are not sent as-is into log
-files, but are converted to their two-digits hexadecimal representation,
-prefixed by the character '#'. The only characters that can now be logged
-without being escaped are between 32 and 126 (inclusive). Obviously, the
-escape character '#' is also encoded to avoid any ambiguity. It is the same for
-the character '"', as well as '{', '|' and '}' when logging headers.
+client. Each of these field is replaced with '-' when no cookie was seen or
+when the option is disabled.
 
-4.2.7) Logging HTTP headers
----------------------------
-As of version 1.1.29, it is now possible to log HTTP headers extracts. It is
-both possible to include request headers and response headers. It is
-particularly useful to know what virtual server the client requested, to know
-the content length during a POST request, or a unique request ID set on a
-previous proxy. In the response, one can search for information about the
-response length, how the server asked the cache to behave, or an object location
-during a redirection. The syntax is :
+Header captures have a different goal. They are useful to track unique request
+identifiers set by a previous proxy, virtual host names, user-agents, POST
+content-length, referrers, etc. In the response, one can search for information
+about the response length, how the server asked the cache to behave, or an
+object location during a redirection. As for cookie captures, it is both
+possible to include request headers and response headers at the same time. The
+syntax is :
 
     capture request  header <name> len <max length>
     capture response header <name> len <max length>
@@ -1279,9 +1460,10 @@
 with a vertical bar '|' without any space. Response headers follow the same
 representation, but are displayed after a space following the request headers
 block. These blocks are displayed just before the HTTP request in the logs.
 Example :
 
-Config:
+  Config:
 
      capture request  header Host len 20
      capture request  header Content-Length len 10
@@ -1292,11 +1474,53 @@
      capture response header Via len 20
      capture response header Location len 20
 
-Log :
+  Log :
+    Aug  9 20:26:09 localhost haproxy[2022]: 127.0.0.1:34014 [09/Aug/2004:20:26:09] relais-http netcache 0/0/162/+162 200 +350 - - ---- {fr.adserver.yahoo.co||http://fr.f416.mail.} {|864|private||} "GET http://fr.adserver.yahoo.com/"
+    Aug  9 20:30:46 localhost haproxy[2022]: 127.0.0.1:34020 [09/Aug/2004:20:30:46] relais-http netcache 0/0/182/+182 200 +279 - - ---- {w.ods.org||} {Formilux/0.1.8|3495|||} "GET http://w.ods.org/sytadin.html HTTP/1.1" 
+    Aug  9 20:30:46 localhost haproxy[2022]: 127.0.0.1:34028 [09/Aug/2004:20:30:46] relais-http netcache 0/2/126/+128 200 +223 - - ---- {www.infotrafic.com||http://w.ods.org/syt} {Apache/2.0.40 (Red H|9068|||} "GET http://www.infotrafic.com/images/live/cartesidf/grandes/idf_ne.png HTTP/1.1" 
+4.2.7) Examples of logs
+-----------------------
+- haproxy[674]: 127.0.0.1:33319 [15/Oct/2003:08:31:57] relais-http Srv1 6559/7/147/6723 200 243 - - ---- 3/5 "HEAD / HTTP/1.0"
+  => long request (6.5s) entered by hand through 'telnet'. The server replied
+     in 147 ms, and the session ended normally ('----')
+- haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/7/14/+30 200 +243 - - ---- 3/3 "GET /image.iso HTTP/1.0"
+  => request for a long data transfer. The 'logasap' option was specified, so
+     the log was produced just before transfering data. The server replied in
+     14 ms, 243 bytes of headers were sent to the client, and total time from
+     accept to first data byte is 30 ms.
+- haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/7/14/30 502 243 - - PH-- 2/3 "GET /cgi-bin/bug.cgi? HTTP/1.0"
+  => the proxy blocked a server response either because of an 'rspdeny' or
+     'rspideny' filter, or because it blocked sensible information which risked
+     being cached. In this case, the response is replaced with a '502 bad
+     gateway'.
+- haproxy[18113]: 127.0.0.1:34548 [15/Oct/2003:15:18:55] relais-http <NOSRV> -1/-1/-1/8490 -1 0 - - CR-- 2/2 "" 
+  => the client never completed its request and aborted itself ('C---') after
+     8.5s, while the proxy was waiting for the request headers ('-R--').
+     Nothing was sent to the server.
+- haproxy[18113]: 127.0.0.1:34549 [15/Oct/2003:15:19:06] relais-http <NOSRV> -1/-1/-1/50001 408 0 - - cR-- 2/2 "" 
+  => The client never completed its request, which was aborted by the time-out
+     ('c---') after 50s, while the proxy was waiting for the request headers ('-R--').
+     Nothing was sent to the server, but the proxy could send a 408 return code
+     to the client.
+- haproxy[18989]: 127.0.0.1:34550 [15/Oct/2003:15:24:28] relais-tcp Srv1 0/5007 0 cD 
+  => This is a 'tcplog' entry. Client-side time-out ('c----') occured after 5s.
+- haproxy[18989]: 10.0.0.1:34552 [15/Oct/2003:15:26:31] relais-http Srv1 3183/-1/-1/11215 503 0 - - SC-- 202/205 "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
+     (config says 'retries 3'), then a 503 error code was sent to the client.
+     There were 202 connections on this proxy, and 205 on the global process.
+     It is possible that the server refused the connection because of too many
+     already established.
 
-Aug  9 20:26:09 localhost haproxy[2022]: 127.0.0.1:34014 [09/Aug/2004:20:26:09] relais-http netcache 0/0/162/+162 200 +350 - - ---- {fr.adserver.yahoo.co||http://fr.f416.mail.} {|864|private||} "GET http://fr.adserver.yahoo.com/"
-Aug  9 20:30:46 localhost haproxy[2022]: 127.0.0.1:34020 [09/Aug/2004:20:30:46] relais-http netcache 0/0/182/+182 200 +279 - - ---- {w.ods.org||} {Formilux/0.1.8|3495|||} "GET http://w.ods.org/sytadin.html HTTP/1.1" 
-Aug  9 20:30:46 localhost haproxy[2022]: 127.0.0.1:34028 [09/Aug/2004:20:30:46] relais-http netcache 0/2/126/+128 200 +223 - - ---- {www.infotrafic.com||http://w.ods.org/syt} {Apache/2.0.40 (Red H|9068|||} "GET http://www.infotrafic.com/images/live/cartesidf/grandes/idf_ne.png HTTP/1.1" 
 
 4.3) HTTP header manipulation
 -----------------------------
@@ -1431,6 +1655,7 @@
 	option forwardfor
 	option httpclose
 
 4.4) Load balancing with persistence
 ------------------------------------
 Combining cookie insertion with internal load balancing allows to transparently
@@ -1492,6 +1717,7 @@
 headers processing. Additionnaly, an alert will be sent in the logs so that
 admins are told that there's something to be done.
 
 4.6) Customizing errors
 -----------------------
 Some situations can make haproxy return an HTTP error code to the client :
@@ -1532,8 +1758,8 @@
 The return code 303 was designed explicitly to force the client to fetch the
 Location URL with the GET method, but there are some browsers pre-dating
 HTTP/1.1 which don't support it. Anyway, most browsers still behave with 302 as
-if it was a 303. In order to allow the user to chose, version 1.1.31 brings two
-new keywords to replace 'errorloc' : 'errorloc302' and 'errorloc303'.
+if it was a 303. In order to allow the user to chose, versions 1.1.31 and 1.2.5
+bring two new keywords to replace 'errorloc' : 'errorloc302' and 'errorloc303'.
 
 They are preffered over errorloc (which still does 302). Consider using
 errorloc303 everytime you know that your clients support HTTP 303 responses..
@@ -1652,7 +1878,7 @@
 echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
 echo 0 > /proc/sys/net/ipv4/tcp_timestamps
 echo 0 > /proc/sys/net/ipv4/tcp_ecn
-echo 0 > /proc/sys/net/ipv4/tcp_sack
+echo 1 > /proc/sys/net/ipv4/tcp_sack
 echo 0 > /proc/sys/net/ipv4/tcp_dsack
 
 # auto-tuned on 2.4
