option dontlog-normal (*) X X X -
option dontlognull (*) X X X -
-- keyword -------------------------- defaults - frontend - listen -- backend -
+option external-check X - X X
option forwardfor X X X X
option forwarded (*) X - X X
option h1-case-adjust-bogus-client (*) X X X -
option httpclose (*) X X X X
option httplog X X X -
option httpslog X X X -
+option idle-close-on-response (*) X X X -
option independent-streams (*) X X X X
option ldap-check X - X X
-option external-check X - X X
option log-health-checks (*) X - X X
option log-separate-errors (*) X X X -
option logasap (*) X X X -
option tcpka X X X X
option tcplog X X X -
option transparent (deprecated) (*) X - X X
-option idle-close-on-response (*) X X X -
external-check command X - X X
external-check path X - X X
persist rdp-cookie X - X X
See also : "log", "http-ignore-probes", "monitor-uri", and
section 8 about logging.
+
+option external-check
+ Use external processes for server health checks
+
+ May be used in the following contexts: tcp, http, log
+
+ May be used in sections : defaults | frontend | listen | backend
+ yes | no | yes | yes
+
+ It is possible to test the health of a server using an external command.
+ This is achieved by running the executable set using "external-check
+ command".
+
+ Requires the "external-check" global to be set.
+
+ See also : "external-check", "external-check command", "external-check path"
+
+
option forwarded [ proto ]
[ host | host-expr <host_expr> ]
[ by | by-expr <by_expr> ] [ by_port | by_port-expr <by_port_expr>]
See also : section 8 about logging.
+option idle-close-on-response
+no option idle-close-on-response
+ Avoid closing idle frontend connections if a soft stop is in progress
+
+ May be used in the following contexts: http
+
+ May be used in sections : defaults | frontend | listen | backend
+ yes | yes | yes | no
+
+ Arguments : none
+
+ By default, idle connections will be closed during a soft stop. In some
+ environments, a client talking to the proxy may have prepared some idle
+ connections in order to send requests later. If there is no proper retry on
+ write errors, this can result in errors while haproxy is reloading. Even
+ though a proper implementation should retry on connection/write errors, this
+ option was introduced to support backwards compatibility with haproxy prior
+ to version 2.4. Indeed before v2.4, haproxy used to wait for a last request
+ and response to add a "connection: close" header before closing, thus
+ notifying the client that the connection would not be reusable.
+
+ In a real life example, this behavior was seen in AWS using the ALB in front
+ of a haproxy. The end result was ALB sending 502 during haproxy reloads.
+
+ Users are warned that using this option may increase the number of old
+ processes if connections remain idle for too long. Adjusting the client
+ timeouts and/or the "hard-stop-after" parameter accordingly might be
+ needed in case of frequent reloads.
+
+ See also: "timeout client", "timeout client-fin", "timeout http-request",
+ "hard-stop-after"
+
+
option independent-streams
no option independent-streams
Enable or disable independent timeout processing for both directions
See also : "option httpchk"
-option external-check
- Use external processes for server health checks
-
- May be used in the following contexts: tcp, http, log
-
- May be used in sections : defaults | frontend | listen | backend
- yes | no | yes | yes
-
- It is possible to test the health of a server using an external command.
- This is achieved by running the executable set using "external-check
- command".
-
- Requires the "external-check" global to be set.
-
- See also : "external-check", "external-check command", "external-check path"
-
-
-option idle-close-on-response
-no option idle-close-on-response
- Avoid closing idle frontend connections if a soft stop is in progress
-
- May be used in the following contexts: http
-
- May be used in sections : defaults | frontend | listen | backend
- yes | yes | yes | no
-
- Arguments : none
-
- By default, idle connections will be closed during a soft stop. In some
- environments, a client talking to the proxy may have prepared some idle
- connections in order to send requests later. If there is no proper retry on
- write errors, this can result in errors while haproxy is reloading. Even
- though a proper implementation should retry on connection/write errors, this
- option was introduced to support backwards compatibility with haproxy prior
- to version 2.4. Indeed before v2.4, haproxy used to wait for a last request
- and response to add a "connection: close" header before closing, thus
- notifying the client that the connection would not be reusable.
-
- In a real life example, this behavior was seen in AWS using the ALB in front
- of a haproxy. The end result was ALB sending 502 during haproxy reloads.
-
- Users are warned that using this option may increase the number of old
- processes if connections remain idle for too long. Adjusting the client
- timeouts and/or the "hard-stop-after" parameter accordingly might be
- needed in case of frequent reloads.
-
- See also: "timeout client", "timeout client-fin", "timeout http-request",
- "hard-stop-after"
-
-
option log-health-checks
no option log-health-checks
Enable or disable logging of health checks status updates
projects / thirdparty / haproxy.git / commitdiff
