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. > > 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): There is an interesting bug regarding this topic: http://issues.apache.org/bugzilla/show_bug.cgi?id=38763 It seems that we do not have to worry about resending POSTs at all because of 8.1.4 of RFC2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html) This means that clients, servers, and proxies MUST be able to recover from asynchronous close events. Client software SHOULD reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request sequence is idempotent (see section 9.1.2). Non-idempotent methods or sequences MUST NOT be automatically retried, although user agents MAY offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding of the application MAY substitute for user confirmation. The automatic retry SHOULD NOT be repeated if the second sequence of requests fails. POST does not seem to be an idempotent method to me. Even retransmitting GETs with parameters in the URL seems dangerous to me. > > 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) Your proposals still make sense as we let the real client decide to do the "dirty" decision work whether to retransmit or not (for comments to them see http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/[EMAIL PROTECTED]). Regards Rüdiger
