On Wed, Jun 09, 2004 at 11:04:23AM -0700, Rasmus Lerdorf wrote: > On Wed, 9 Jun 2004, Joe Orton wrote: > > > On Wed, Jun 09, 2004 at 09:21:07AM -0700, Rasmus Lerdorf wrote: > > > Don't see that anywhere. Either eaten by spam filters or a gerbil. > > > > > > Anyway, I don't understand why this would have broken mod_dav. If mod_dav > > > wants a keepalive connection it should determine this prior to the ap_die > > > and set conn->keepalive to 1. Or am I missing something with respect to > > > what mod_dav is doing here? I suppose we could add an ugly exception for > > > a PROPFIND here, but I'd like to make sure that is actually needed. > > > > >From my debugging: mod_dav doesn't actually get involved at all, the > > check_user_id handler from the auth module returns AUTH_REQUIRED for the > > request, and ap_set_keepalive is not called before ap_die is invoked in > > that case. r->connection->keepalive has never been changed from 0 when > > the test in question is reached - it's called later by > > ap_send_error_response, but that's too late. > > Just to save me some debugging time, are you saying that on a 401 we call > ap_set_keepalive after calling ap_die or that we are not calling > ap_set_keepalive at all? The former should never happen as far as I am > concerned, and the latter should be fine as the request simply won't be a > keepalive request and nothing should expect it to be.
When ap_die() is called, ap_set_keepalive() has not been called, and r->connection->keepalive is set to 0, as it was initialized so. The last thing ap_die does is call ap_send_error_response, which calls ap_send_http_header, which calls ap_set_keepalive, which sets r->connection->keepalive = 1. FWIW, "r->connection->keeaplive == 0" is documented in the header to mean "undecided", not specifically "no keep alive", as you seem to want to use it. joe
