httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject Re: Issue with persistent http proxy backend connection
Date Wed, 11 Oct 2006 21:09:47 GMT
On 10/11/06, Ruediger Pluem <rpluem@apache.org> wrote:
> 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.

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

A non-compliant behavior (i.e., not default Apache behavior) which
would be useful would be to wait for 100-Continue before sending POST
bodies.  If connection is dropped before receiving 100-Continue, try
on a new connection.

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

<Location /proxy/all_gets_are_idempotent>
SetEnv foomatic=1
</Location>

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

Unfortunately, our own hint in the response is not useful when sent by
a child process that is being terminated due to excessive idle
processes/threads or MaxRequestsPerChild, since we can break out of
ap_process_connection right after telling the client they have N
seconds to send the next request.  This will happen enough to be
disturbing, though perhaps not often enough to quickly diagnose it.
("Gosh, try turning off proxy keepalive and see if it gets better.  If
so, that's your permanent solution.")

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

(In case it isn't stated explicitly already)  No such retry would be
performed on the initial request sent on a connection, right?

Mime
View raw message