Actually I tried to figure out what results when a configured ProxyTimeout has expired. My testcase was as follows: - a nVH with a working ProxyPass and ProxyPassReverse set - low ProxyTimeout (2) setting within the nVH - iptables rule to simply drop incoming proxied host's traffic The connection hangs until Apache's main Timeout value (default setting) from UAs point of view and it doesn't matter if ProxyTimeout was set or not. Additionally I tried to set ProxyTimeout in the main config with identical behaviour (leaving ProxyPass(Reverse) in its place). I didn't try ProxyTimeout within a configuration for Apache as regular client proxy, so it might be entailed with ProxyPass(Reverse) merely.
Same behaviour with 2.0.40
From investigating this, ProxyTimeout only applies after the connection is successfully established, which won't happen if the packets are dropped. Will check further to see if this is correct behaviour or not.
*** Bug 23122 has been marked as a duplicate of this bug. ***
Confirmed - the ProxyTimeout applies after a successful connection. To test this, you need to convince your test connection to connect successfully, but then not send any data. The proxy should wait the timeout length for a response, and give up if this time is reached. I'm closing this bug for now, if you have further problems, reopen it.
I'm facing this problem with IHS2.042.2 (Apache/2.0.46) on AIX. Simply put, I have an upstream application server that takes about 15mins to generate a large report. The reverse proxy returns a 502 error to the client after the connection timeout period elapses (which is normal). I can overcome the problem by increasing the Timeout directive, but believe it would be more appropriate to use the ProxyTimeout directive. This does not, however, produce the desired effect. Perhaps the last comment "ProxyTimeout applies after a successful connection" could be clarified in more detail?
My observation is ProxyTimeout (by 2.0.51) rather sets the Connect timeout, not the read timeout. Another bug regarding ProxyTimeout is, that neither Timeout nor ProxyTimeout apply when an SSL proxy connection ("CONNECT") is established. These connections never time out.
Timeout for socket in case of proxy request set in modules/proxy/mod_proxy.c by function ap_proxy_connect_to_backend(): /* Set a timeout on the socket */ if (conf->timeout_set == 1) { apr_socket_timeout_set(*newsock, conf->timeout); } else { apr_socket_timeout_set(*newsock, s->timeout); } GDB show, that conf->timeout_set is 0, and timeout get from global config (from "Timeout" directive). Note, that other *_set variable never used in mod_proxy* for check something. I don't know why conf->timeout_set is zero in ap_proxy_connect_to_backend(). May be need compared 2 functions from modules/proxy/mod_proxy.c: create_proxy_config and merge_proxy_config Check this: ps->timeout= (overrides->timeout_set == 0) ? base->timeout : overrides->timeout; If overrides->timeout_set equal 0, than ps->timeout setted, but may be we need set too : ps->timeout_set = 1; /* because timeout set always, timeout_set is always setted */ ? But probably we don't need use *_set variable anywhere in proxy_utils to check. next patch work in my environment: diff -u modules/proxy/proxy_util.c.save modules/proxy/proxy_util.c --- modules/proxy/proxy_util.c.save Tue Nov 23 14:47:48 2004 +++ modules/proxy/proxy_util.c Tue Nov 23 14:48:46 2004 @@ -1128,7 +1128,7 @@ #endif /* Set a timeout on the socket */ - if (conf->timeout_set == 1) { + if (conf->timeout != 0) { apr_socket_timeout_set(*newsock, conf->timeout); } else {
Created attachment 15511 [details] 2.0.53: ensures <opt>_set properties are set correctly in merge_proxy_config ProxyTimeout directive is ignored because the timeout_set property gets cleared in merge_proxy_config. Attached patch resolves this problem
Created attachment 15512 [details] 2.1.3-beta: ensures <opt>_set properties are set correctly in merge_proxy_config
This bug just bit me too. The patch in attachment 15511 [details] looks good to me, applies cleanly (once it's been dos2unix'd) to 2.0.54, and I can confirm fixes the bug. I'd certainly like this to be applied. I would also suggest that the documentation is updated to clarify that this timeout is for *establishing* the connection only (at least that's what the code and my tests show); and that the core Timeout directive will affect the timeout for an established connection. I'm happy to knock up a patch with suitable text - just say the word.
So this bug is still in both 2.0.55 and the trunk. I am confirming that the already supplied attachments are still good for the respective (2.0 and 2.1) HEADs in SVN. Could we please get these applied?
Bumping because this bug *still* exists in 2.0.58 and 2.2.4 and trunk. Will attach an updated patch against trunk. This should also apply against the HEAD of 2.2.x branch (bar lines numbers being slightly off, but given the context it should apply).
Created attachment 19589 [details] patch against current trunk
(In reply to comment #13) > Created an attachment (id=19589) [edit] > patch against current trunk > I've just applied that one to trunk (with your tabs/indentation fixed). Stuart, from memory I think I've seen your name on quite a few bugs, and they tend to be of the kind that look valid but need some effort to check. These may tend to pass under the radar here. Maybe it would be more productive for you to participate in dev@httpd with such points.
(In reply to comment #14) > I've just applied that one to trunk (with your tabs/indentation fixed). Great, thank you. Apologies for indentation, I based it off a patch we've been using for a while on a local build and totally forgot to check for tabs<->spaces. > Stuart, from memory I think I've seen your name on quite a few bugs, and they > tend to be of the kind that look valid but need some effort to check. These > may tend to pass under the radar here. Maybe it would be more productive for > you to participate in dev@httpd with such points. I'm already a subscriber. In fact, I brought this bug up there before: http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=113257650709794&w=2 - but got no response. I actually asked yesterday on Freenode's #apache what the best method to push bugs was, but people only seemed to be dealing with user queries. Is there a more developer-centric channel? I was planning to make another post to the mailing list after resubmitting these patches. I certainly appreciate that patches aren't always obvious in their effect; and it's good that commiters don't just apply them without thought. :) I'm more than happy to help out and give examples/explain my working. If you'd like to continue the discussion on how reporters/developers without commit access can get their bugs (valid ones and not) dealt with more readily, let's take if off this bug. Please feel free to email me directly, or bring it up on dev@ and I'll join in.
Created attachment 19602 [details] patch against current 2.2.x HEAD
Created attachment 19606 [details] patch against current 2.0.x HEAD
I had applied the patch in 2.0.59 and 2.2.4 versions, and doesn't work. I try in Solaris and Linux environment.
What exactly doesnt work?
(In reply to comment #19) > What exactly doesnt work? I guess he is hit by http://mail-archives.apache.org/mod_mbox/httpd-dev/200705.mbox/%3c464F4E80.9020202@apache.org%3e
The ProxyTimeout setting for mod_proxy is not working as described. According to the documentation, ProxyTimeout should "fail gracefully instead of waiting however long it takes the server to return." This means that ProxyTimeout setting should cause mod_proxy to return an error back to the user instead of waiting until the Server's main Timeout value is reached, which it is doing now. It seems the ProxyTimeout is currently ignored as everyone else here describes. For example if Apache has a Timeout of 60 seconds and ProxyTimeout is 10 seconds, then mod_proxy should return an error message back to the user if after 10 seconds it did not receive a response to the server it connected to. Please fix. Thanks.
Fixed in trunk as r546128, r550514. Backported to 2.2.x as r556972 (http://svn.apache.org/viewvc?view=rev&rev=556972).