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 > 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): 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? Regards Rüdiger
