httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <>
Subject Re: svn commit: r378032 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy_http.c modules/proxy/proxy_util.c
Date Mon, 20 Feb 2006 13:51:07 GMT
On Mon, Feb 20, 2006 at 12:52:31PM +0100, Plüm, Rüdiger, VIS wrote:
> > I found only one pertinent error message in the log:
> > 
> > [Mon Feb 20 10:40:08 2006] [debug] proxy_util.c(2118): proxy: HTTP: 
> > connection complete to (localhost.localdomain) 
> But this is HTTP to the backend isn't it?

Yup - this test covers both http/ssl to the backend with http/ssl to the 
client, omitting the http->http case.

> > [Mon Feb 20 10:40:08 2006] [error] (32)Broken pipe: proxy: 
> > pass request 
> > body failed to (localhost.localdomain)
> > [Mon Feb 20 10:40:08 2006] [error] (32)Broken pipe: proxy: 
> > pass request 
> > body failed to (localhost.localdomain) from 
> > ()
> > 
> > ...perhaps a persistent connection being closed by the 
> > backend, and the 
> > proxy only finding out about this half way through sending a request 
> Also my guess. See also point 2 in
> Is it possible to increase the keepalive timeout temporarily for a test run?
> This would give a valuable hint?

Yup, that fixes the failures, though the test is hanging for a 
while in the two places it was failing before.

There are a *lot* of these weird 408 (HTTP_REQUEST_TIME_OUT) errors in 
the access_log, I notice - it looks like these were happening even 
before the proxy changes: - - [20/Feb/2006:13:17:44 +0000] "-" 408 223 - - [20/Feb/2006:13:17:45 +0000] "POST /eat_post HTTP/1.1" 200 6 - - [20/Feb/2006:13:17:45 +0000] "POST /eat_post HTTP/1.0" 200 6 - - [20/Feb/2006:13:17:45 +0000] "-" 408 223

that code is only generated new request parsing code.  Brian?

> > body?  Hard to handle that in the proxy - probably best to just 
> > ungracefully terminate the connection to the client in that case, it 
> > should then resend appropriately too.
> Yes, if get into this situation I guess we have no better chance. But that should already
> be the reaction to this kind of situation.
> Ok, I see that this is currently not the case (at least not if we fail during
> sending the reponse). The following patch should sent
> a 502 to the client in such cases and close the connection to the client:

That's not what I meant.  This is a bit tricky.  Here's a restatement of 
the problem, just to make sure we're talking about the same thing:

If a client reuses a connection to an HTTP server which has been held 
open persistently, there is a risk that the connection may be closed 
either beforehand or simultaneously to when the client tries to reuse 
it.  So, it's quite normal to start sending a POST request with a body, 
and then half way through sending the request body, you get an TCP RST 
or a FIN.  HTTP/1.1 clients have logic to open a new connection and 
resend the request if that happens.

If the "client" in this case is the proxy, then the proxy may not be 
able to resend the whole request body if it is streaming it through and 
may already have discarded the first half by the time it sees the 

If the proxy has the correct logic then this can be handled correctly. 
In handling a request which includes a body (and the body will 
not/cannot be cached entirely in memory):

a) if the connection to the client has been kept open persistently (i.e.  
r->connection->keepalives > 1), then it is safe to forward the request 
on a connection to the backend which has itself been held open 
persistently.  If the backend connection is closed whilst sending the 
request/body, then the connection to the client should also immediately 
be closed without sending a response.

b) if the connection to the client has *not* been kept open 
persistently, then it is only safe to forward a request which includes a 
request body on a newly opened connection to the backend.  (since such a 
connection is not vulnerable to a persistent connection timeout)

Does that make sense?



View raw message