On Nov 13, 2007 10:38 AM, Jeff Trawick <[EMAIL PROTECTED]> wrote:
> On Nov 13, 2007 8:57 AM, Plüm, Rüdiger, VF-Group
> <[EMAIL PROTECTED]> wrote:
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Jeff Trawick
> > > Gesendet: Dienstag, 13. November 2007 14:31
> > > An: dev@httpd.apache.org
> > > Betreff: keepalive connections and exiting MPM processes
> >
> > >
> > >
> > > 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.
>
> ...
>
>
> > > It isn't so clear how to handle the remaining window, in which the MPM
> > > process starts exiting while we send the response (and after we've
> > > already determined the keepalive setting).
> > >
> > > From ap_process_http_connection():
> > >
> > > if (r->status == HTTP_OK) {
> > > cs->state = CONN_STATE_HANDLER;
> > > ap_process_request(r);
> > > r = NULL;
> > > }
> > >
> > > if (c->keepalive != AP_CONN_KEEPALIVE || c->aborted)
> > > break;
> > >
> > > XXXXXXXXXXX
> > > We could skip checking for graceful exit here since
> > > it is checked
> > > as part of the keepalive determination, but the MPM process
> > > could remain active much longer than expected (maybe we just
> > > downloaded a very large file).
> > > XXXXXXXXXXX
> > >
> > > if (ap_graceful_stop_signalled())
> > > break;
> > >
> > > For the remaining timing window, I'm afraid that a vhost-specific
> > > setting is needed to control whether we respect the connection
> > > keepalive setting or the MPM state. (The latter is apparently good
> >
> > I guess we can leave it as it is in this situation. Although we SHOULD
> > send connection: close if want to close the connection it is no MUST
> > (8.1.2.1, last sentence first paragraph). And for pipelined requests the
> > client must be prepared to resend anyway if we do not process all pipelined
> > requests (8.1.2.2).
>
> Apart from the SHOULD vs. MUST is the end-user issue when the client
> software can't or won't retry automatically when confronted with a
> validly-dropped connection ;)
Here's a patch to address that issue:
http://people.apache.org/~trawick/keepalive.txt
(KeepAliveWhileExiting On|Off, default Off)
It comes down to this check in ap_process_http_connection():
while ((r = ap_read_request(c)) != NULL) {
...
if (c->keepalive != AP_CONN_KEEPALIVE || c->aborted)
break;
...
if (!c->base_server->keep_alive_while_exiting &&
ap_graceful_stop_signalled())
break;
}
The only commentary I've seen on the general idea so far is that the
RFC doesn't force us to respect that persistence.
