Caddy: Add reliable timeouts to fastcgi upstream

[git001]

1. What version of Caddy are you using (caddy -version)?

caddy -version
Caddy 0.10.12 (non-commercial use only)

2. What are you trying to do?

serve php backend via fastcgi module

3. What is your entire Caddyfile?

(netlify-ips) {

  realip {
    from 52.59.190.70/32
    from 54.93.37.149/32
    from 54.229.14.125/32
    from 35.158.119.227/32
  }
}

static.MYDOMAIN.com {
  root /home/data/webroot
  gzip
  log / stdout "{remote} - {user} [{when}] \"{method} {uri} {proto}\" {status} {size} \"{>Referer}\" \"{>User-Agent}\""
}

app-dev56.MYDOMAIN.com:80 {
  tls off
  redir / https://{hostonly}/
  redir /registry https://MYDOMAIN.com/index.php?func=register
}

app-dev56.MYDOMAIN.com {

  import netlify-ips

  redir /registry https://{hostonly}/index.php?func=register

  root /home/phpapp/app/web-app-dev56

  log / stdout "{remote} - {user} [{when}] \"{method} {uri} {proto}\" {status} {size} \"{>Referer}\" \"{>User-Agent}\""

  fastcgi / 127.0.0.1:7056 php {
    except /config.php
    read_timeout 30s
  }
}

4. How did you run Caddy (give the full command and describe the execution environment)?

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.4 LTS
Release:        16.04
Codename:       xenial

/usr/local/bin/caddy -log stdout -agree=true -email MY-EMAIL -conf=/etc/caddyserver/caddyfile -root=/var/tmp

5. No timeouts

As far as I have seen in the code are no default timeouts for connect_timeout, read_timeout and send_timeout.
I suggest to set some default values for these timeouts, similar to the proxy module http.proxy.

Proposal: 60s

[tobya]

Hi @git001
Thank you for the feature request. We have had issues before when we set default timeouts, but 60s seems like a reasonable timeout to me.

[theodesp]

I'm willing to work on it

[mholt]

I don't understand; why is setting a default timeout for fastcgi preferable?

[theodesp]

maybe @git001 could elaborate some use cases

[git001]

maybe @git001 could elaborate some use cases

I think that in general a infinite timeout isn't reliable.
You don't know which time out will interfere the communitation chain client <-> proxy (=caddy) <-> appserver.
I prefer to know, at least from proxy point of view, which timeout are set.
I assume that this was also the reason for the defaults in the http proxy module.

Maybe the net plugin could also have some reliable defaults.

[SmilingNavern]

I am not sure if this is still required, but i like the idea of default timeouts. Can i work on this? @mholt

[mholt]

But why should there be default timeouts? I also seem to remember problems when there were hidden/default timeouts set.

[SmilingNavern]

Usually you need timeout to prevent system from leaking any resources, because sessions without timeout can consume your resources for very long.

In case of php there are already hidden/default timeouts in php itself(like max_execution_time).

In general i agree that timeouts are more reliable and you need them to mitigate issues with leaking resources which you are unaware of.

[git001]

I agree with @SmilingNavern to have some good default values.
I prefer that the proxies inside caddy should have the same default values, e.g. http-proxy, fcgi-proxy, ....

[mholt]

Alright -- go ahead and propose timeouts and we'll just make sure to document them, along with a way to turn them off if need-be.

[git001]

I think 60s are good values to start.

[SmilingNavern]

I believe we can close this issue. @mholt