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 127.0.0.1:8529 (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 127.0.0.1:8529 (localhost.localdomain) > > [Mon Feb 20 10:40:08 2006] [error] (32)Broken pipe: proxy: > > pass request > > body failed to 127.0.0.1:8529 (localhost.localdomain) from > > 127.0.0.1 () > > > > ...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 > http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/ajax/[EMAIL > PROTECTED] > 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: 127.0.0.1 - - [20/Feb/2006:13:17:44 +0000] "-" 408 223 127.0.0.1 - - [20/Feb/2006:13:17:45 +0000] "POST /eat_post HTTP/1.1" 200 6 127.0.0.1 - - [20/Feb/2006:13:17:45 +0000] "POST /eat_post HTTP/1.0" 200 6 127.0.0.1 - - [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 RST/FIN/. 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? Regards, joe
