Bug 11540 - ProxyTimeout ignored
Summary: ProxyTimeout ignored
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy (show other bugs)
Version: 2.0-HEAD
Hardware: PC Linux
: P3 normal with 2 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: PatchAvailable
: 23122 (view as bug list)
Depends on:
Reported: 2002-08-07 21:21 UTC by Christoph Vogel
Modified: 2007-07-25 13:01 UTC (History)
3 users (show)

2.0.53: ensures <opt>_set properties are set correctly in merge_proxy_config (1.76 KB, patch)
2005-06-22 15:16 UTC, Graham Collinson
Details | Diff
2.1.3-beta: ensures <opt>_set properties are set correctly in merge_proxy_config (1.97 KB, patch)
2005-06-22 15:24 UTC, Graham Collinson
Details | Diff
patch against current trunk (1.94 KB, patch)
2007-02-14 04:17 UTC, Stuart Children
Details | Diff
patch against current 2.2.x HEAD (1.97 KB, patch)
2007-02-16 03:35 UTC, Stuart Children
Details | Diff
patch against current 2.0.x HEAD (1.77 KB, patch)
2007-02-16 06:22 UTC, Stuart Children
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Vogel 2002-08-07 21:21:59 UTC
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.
Comment 1 Christoph Vogel 2002-08-19 21:01:31 UTC
Same behaviour with 2.0.40
Comment 2 Graham Leggett 2003-04-15 16:26:58 UTC
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.
Comment 3 Dave Lee 2004-05-04 22:12:17 UTC
*** Bug 23122 has been marked as a duplicate of this bug. ***
Comment 4 Graham Leggett 2004-05-21 22:16:28 UTC
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.
Comment 5 Anthony Pahitas 2004-09-15 13:21:30 UTC
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?
Comment 6 Georg v. Zezschwitz 2004-10-15 14:24:06 UTC
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.
Comment 7 Maxim Kozin 2004-11-23 14:18:41 UTC
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

I don't know why conf->timeout_set is zero in ap_proxy_connect_to_backend().

May be need compared 2 functions from
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

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 @@
         /* Set a timeout on the socket */
-        if (conf->timeout_set == 1) {
+        if (conf->timeout != 0) {
             apr_socket_timeout_set(*newsock, conf->timeout);
         else {

Comment 8 Graham Collinson 2005-06-22 15:16:56 UTC
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
Comment 9 Graham Collinson 2005-06-22 15:24:00 UTC
Created attachment 15512 [details]
2.1.3-beta: ensures <opt>_set properties are set correctly in merge_proxy_config
Comment 10 Stuart Children 2005-09-01 20:37:26 UTC
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.
Comment 11 Stuart Children 2005-11-08 13:15:02 UTC
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?
Comment 12 Stuart Children 2007-02-14 04:15:51 UTC
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).
Comment 13 Stuart Children 2007-02-14 04:17:10 UTC
Created attachment 19589 [details]
patch against current trunk
Comment 14 Nick Kew 2007-02-14 05:01:35 UTC
(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.
Comment 15 Stuart Children 2007-02-15 02:50:37 UTC
(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.
Comment 16 Stuart Children 2007-02-16 03:35:21 UTC
Created attachment 19602 [details]
patch against current 2.2.x HEAD
Comment 17 Stuart Children 2007-02-16 06:22:55 UTC
Created attachment 19606 [details]
patch against current 2.0.x HEAD
Comment 18 Jordi Garcia 2007-04-17 05:56:26 UTC
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.
Comment 19 Davi Arnaut 2007-06-08 08:35:06 UTC
What exactly doesnt work?
Comment 20 Ruediger Pluem 2007-06-08 08:45:49 UTC
(In reply to comment #19)
> What exactly doesnt work?

I guess he is hit by

Comment 21 Alon Dakik 2007-07-25 12:54:35 UTC
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. 

Comment 22 Ruediger Pluem 2007-07-25 13:01:38 UTC
Fixed in trunk as r546128, r550514. Backported to 2.2.x as r556972