On Nov 13, 2007, at 8:30 AM, Jeff Trawick wrote:
When the MPM process handling the connection is or will be exiting, we
can incorrectly tell the client that the connection will be held open
after the current request. This can result in user intervention
(retry the POST?) or failures for some requests sent subsequently on
that connection.
The case where we already know we're exiting at the time we determine
the keep-alive setting is simple to handle:
#include "mod_core.h"
@@ -187,6 +188,7 @@
* or they're a buggy twit coming through a HTTP/1.1 proxy
* and the client is requesting an HTTP/1.0-style keep-alive
* or the client claims to be HTTP/1.1 compliant
(perhaps a proxy);
+ * and this MPM process is not already exiting
* THEN we can be persistent, which requires more headers be
output.
*
* Note that the condition evaluation order is extremely
important.
@@ -212,7 +214,8 @@
&& (!apr_table_get(r->subprocess_env, "nokeepalive")
|| apr_table_get(r->headers_in, "Via"))
&& ((ka_sent = ap_find_token(r->pool, conn, "keep-alive"))
- || (r->proto_num >= HTTP_VERSION(1,1)))) {
+ || (r->proto_num >= HTTP_VERSION(1,1)))
+ && !ap_graceful_stop_signalled()) {
int left = r->server->keep_alive_max - r->connection-
>keepalives;
r->connection->keepalive = AP_CONN_KEEPALIVE;
Concept-wise, this makes sense...
