httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Issue with persistent http proxy backend connection
Date Wed, 11 Oct 2006 19:53:25 GMT
There is an issue with the proxy code that if a request is sent over
a persistent backend connection (currently only looking at the http case, not
sure if the same thing can happen for other backends like ajp and fastcgi)
it could happen that this connection gets closed by the backend for timeout reasons
after the is_connected check and before / while sending the request.
For reference see e.g:

http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/%3c20060220135107.GA4335@redhat.com%3e
http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/%3c43F0FBFD.6040403@apache.org%3e

I had some virtual hackathon with Joe Orton via IRC on this topic and try to summarize our
findings:

1. RFC 2616 does not allow clients to resend a non idempotent request in those cases without
   user interaction (8.1.4). It is concluded that the same applies to a proxy in this case.

2. Although GET is mentioned to be idempotent in RFC 2616 (9.1.2) along with some other methods
   it is not a good idea to regard a GET / HEAD with query parameters to be idempotent.

3. Sometimes servers (including httpd) include a keep-alive header in their response with
the parameter
   timeout set. This can give a hint when the backend will close its persistent connection
due to a
   timeout.

If there is a non idempotent request to the proxy and there is not enough timeout time left
on the
backend connection, then close the pooled backend connection and forward the request to the
backend via a new connection. The size of "enough timeout time left" is not defined yet and
besides a good default value for it, there should be the possibility to change that via configuration.
If the server does not sent the timeout parameter back in its reponse, it is regarded as 0.

If there is a idempotent request, resent it if it failed because of a read / write failure
to the
backend *before* the first successful read from the backend. It is important that this is
really
a socket error. Simply checking for a failure of ap_proxy_http_request is not *enough*, because
it should not be resent if it failed due to some other problem (e.g. parsing error).


Regards

RĂ¼diger





Mime
View raw message