httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
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 22:01:00 GMT

On 02/20/2006 02:51 PM, Joe Orton wrote:

> 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.

Do you have any examples for such clients? All common browsers?

> 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):

Thanks for explanation. Now I understand what you mean

> 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.

Ok. Possibly tricky to implement. From my first view it would require the
ap_http_header_filter to be removed, r->connection->keepalive set to
AP_CONN_CLOSE and an eos sent down the chain, but I am neither sure that this is

1. RFC compliant
2. Good code

> 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)

In principle we know too late if the request contains a body or not
(checked in ap_proxy_http_request, but we would need to know in
ap_proxy_connect_backend). We could check for C-L or T-E in headers_in
as a marker for a possible request body. But this could be used by
evil / bad clients to close pooled backend connections without actually
sending a request body. Or is this assumption to paranoid?



View raw message