Added timeouts to haproxy config

[Ferios08]

added after noticing these warnings in the HAProxy logs:

[marcosnils]

Thx for the contribution. I'm trying to think if the timeout client/server properties could actually hurt long-living connections like websocket and any potential traffic going through the proxy. Have you considered this?

[Ferios08]

This is actually a good point.
So should we increase the timeout values or just leave them empty?

[marcosnils]

So should we increase the timeout values or just leave them empty?

I guess we can set them to the same default values they have initially. Not sure what haproxy uses if you don't specify them.

[Ferios08]

after checking haproxy, the default value is 10 seconds:

https://www.haproxy.org/download/1.4/doc/configuration.txt#:~:text=stats%20timeout%20%3Ctimeout%2C%20in%20milliseconds,value%20with%20%22stats%20timeout%22.

[marcosnils]

https://www.haproxy.org/download/1.4/doc/configuration.txt#:~:text=stats%20timeout%20%3Ctimeout%2C%20in%20milliseconds,value%20with%20%22stats%20timeout%22.

IIUC that's for the stats timeout, correct?

timeout client doesn't mention anything about default I think:

timeout client <timeout>
timeout clitimeout <timeout> (deprecated)
  Set the maximum inactivity time on the client side.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments :
    <timeout> is the timeout value specified in milliseconds by default, but
              can be in any other unit if the number is suffixed by the unit,
              as explained at the top of this document.

  The inactivity timeout applies when the client is expected to acknowledge or
  send data. In HTTP mode, this timeout is particularly important to consider
  during the first phase, when the client sends the request, and during the
  response while it is reading data sent by the server. The value is specified
  in milliseconds by default, but can be in any other unit if the number is
  suffixed by the unit, as specified at the top of this document. In TCP mode
  (and to a lesser extent, in HTTP mode), it is highly recommended that the
  client timeout remains equal to the server timeout in order to avoid complex
  situations to debug. It is a good practice to cover one or several TCP packet
  losses by specifying timeouts that are slightly above multiples of 3 seconds
  (eg: 4 or 5 seconds).

  This parameter is specific to frontends, but can be specified once for all in
  "defaults" sections. This is in fact one of the easiest solutions not to
  forget about it. An unspecified timeout results in an infinite timeout, which
  is not recommended. Such a usage is accepted and works but reports a warning
  during startup because it may results in accumulation of expired sessions in
  the system if the system's timeouts are not configured either.

  This parameter replaces the old, deprecated "clitimeout". It is recommended
  to use it to write new configurations. The form "timeout clitimeout" is
  provided only by backwards compatibility but its use is strongly discouraged.

  See also : "clitimeout", "timeout server".```

^ this is from the page that you shared.

[Ferios08]

After reading well the docs, you're kinda right,
but I've found something which I've put bold

timeout client <timeout>
timeout clitimeout <timeout> (deprecated)
  Set the maximum inactivity time on the client side.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments :
    <timeout> is the timeout value specified in milliseconds by default, but
              can be in any other unit if the number is suffixed by the unit,
              as explained at the top of this document.

  The inactivity timeout applies when the client is expected to acknowledge or
  send data. In HTTP mode, this timeout is particularly important to consider
  during the first phase, when the client sends the request, and during the
  response while it is reading data sent by the server. The value is specified
  in milliseconds by default, but can be in any other unit if the number is
  suffixed by the unit, as specified at the top of this document. In TCP mode
  (and to a lesser extent, in HTTP mode), it is highly recommended that the
  client timeout remains equal to the server timeout in order to avoid complex
  situations to debug. **It is a good practice to cover one or several TCP packet
  losses by specifying timeouts that are slightly above multiples of 3 seconds
  (eg: 4 or 5 seconds).**

  This parameter is specific to frontends, but can be specified once for all in
  "defaults" sections. This is in fact one of the easiest solutions not to
  forget about it. **An unspecified timeout results in an infinite timeout, which
  is not recommended. Such a usage is accepted and works but reports a warning
  during startup because it may results in accumulation of expired sessions in
  the system if the system's timeouts are not configured either.**

Setting client timeout to 1m is a fair enough value I guess, for long-living connections and accumulation of expired sessions I guess.