proxy keepalive handling

[Joe Orton <jo...@redhat.com>]

(somewhat more appropriate $SUBJECT now ;)

On Thu, Feb 23, 2006 at 10:20:08PM +0100, Ruediger Pluem wrote:
> 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)
...
> POST does not seem to be an idempotent method to me.

Excellent point, yes. This could imply that case (a) in my proposal 
should be modified such that it is only used for methods known to be 
idempotent.  This would however require the proxy to have knowledge of 
whether any arbitrary HTTP method is idempotent or not!

But - if the downstream client sent a request with a non-idempotent 
method on a keptalive connection, then it is already risking having to 
resend said request after a connection timeout.  So it would not seem 
unreasonable to ignore this case, and leave it to the discretion of the 
client.  (if clients will only send non-idempotent requests as the first 
request on the connection, then my case (b) will always apply to them)

w.r.t. your other questions (sorry for the slow reponses):

- I haven't tested how The Browsers behave:, but I'd bet that they will 
both send POST requests on keptalive connections, and will automatically 
retry them if the connection is closed.

- I think the "A client, server, or proxy MAY close the transport 
connection at any time." statement in 8.1.4 means it is RFC-compliant to 
have the proxy just drop the connection without sending a response like 
this.

- I don't think that allowing a client to force the proxy to close a 
backend connection is in any way a security issue; it doesn't cause a 
denial of service or anything.  There are various cases in 2616, such as 
an unrecognized content-coding in the request, which require the 
*server* to close the connection anyway.

> Even retransmitting GETs with parameters in the URL seems dangerous to 
> me.

The opposing view is that 2616 says that GET is idempotent, and 2616 is 
The Law.  Pick one ;)

Regards,

joe