The default timeout when using HTTPD & PHP is only 60 seconds

What version of Cloud Foundry and CF CLI are you using? (i.e. What is the output of running cf curl /v2/info && cf version?

{
   "name": "",
   "build": "",
   "support": "https://support.run.pivotal.io",
   "version": 0,
   "description": "Cloud Foundry sponsored by Pivotal",
   "authorization_endpoint": "https://login.run.pivotal.io",
   "token_endpoint": "https://uaa.run.pivotal.io",
   "min_cli_version": "6.22.0",
   "min_recommended_cli_version": "latest",
   "api_version": "2.84.0",
   "app_ssh_endpoint": "ssh.run.pivotal.io:2222",
   "app_ssh_host_key_fingerprint": "e7:13:4e:32:ee:39:62:df:54:41:d7:f7:8b:b2:a7:6b",
   "app_ssh_oauth_client": "ssh-proxy",
   "routing_endpoint": "https://api.run.pivotal.io/routing",
   "doppler_logging_endpoint": "wss://doppler.run.pivotal.io:443",
   "user": "fb1b3b31-5963-464a-8c0f-40532114f2ac"
}

$ cf -v
cf version 6.26.0+9c9a261fd.2017-04-06

What version of the buildpack you are using?

4.3.33

If you were attempting to accomplish a task, what was it you were attempting to do?

If you send a slow request (>60s) to a PHP application, the FPM request from HTTPD to PHP will timeout.

2017-06-08T16:07:04.37-0400 [RTR/1] OUT php-info.cfapps.io - [2017-06-08T20:06:04.319+0000] "GET /slow.php?time=61 HTTP/1.1" 503 0 299 "-" "curl/7.54.0" "10.10.66.216:53173" "10.10.147.129:61028" x_forwarded_for:"50.4.153.215" x_forwarded_proto:"http" vcap_request_id:"4ae17531-0ddb-491a-69db-b98b7e7cc777" response_time:60.060113409 app_id:"54cccad6-9bba-45c6-bb52-83f56d765ff4" app_index:"0" x_b3_traceid:"d09e185aa1d1468c" x_b3_spanid:"d09e185aa1d1468c" x_b3_parentspanid:"-"
2017-06-08T16:07:04.37-0400 [RTR/1] OUT
2017-06-08T16:07:04.38-0400 [APP/PROC/WEB/0] OUT 20:07:04 httpd   | [Thu Jun 08 20:07:04.382603 2017] [proxy_fcgi:error] [pid 61:tid 140154379433728] (70007)The timeout specified has expired: [client 50.4.153.215:4484] AH01075: Error dispatching request to : (polling)

Note how the response time is almost exactly 60s. This is coming from the Timeout here.

What did you expect to happen? What was the actual behavior?

A timeout of 60s seems unnecessarily short. The gorouter will let a request run for 900s by default. It would be nice if the build pack could do something like gorouter timeout - 5s. I’m not sure how you’d get the gorouter’s timeout value though in the build pack. Maybe we could make this more easily configurable for users? Worst case, I think it would be reasonable to have a larger default timeout like something just shy of the gorouter’s default.

I think the idea would be to append a ProxyTimeout setting here.

Ex:

# Allow the proxy to wait for up to 895 seconds
#  this is just short of the default gorouter timeout of 900s
ProxyTimeout 895

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

[dmikusa]

There are hundreds of notice and warning messages in that file. It’s going to be impossible for me to tell you anything from it. I would suggest clearing those up. Perhaps it’ll help you narrow in on the issue.

[dmikusa]

The default timeout is 60s. In your case, it’s only making it 30s, so I don’t think you are hitting the default timeout, at least not the one referenced in this issue. You are also getting a 499 response code, not 504. 499 means the client gave up before the response completed. In short, whatever is consuming the request from your app is not waiting long enough.