On Wed, 9 Jun 2004, Joe Orton wrote: > 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.
Well, we have a bunch of cases where we leave it "undecided" when it is decidedly not undecided. For example, when I configure a server to exlicitly not use keepalives and restrict Post requests with a Limit Post clause, I don't expect a POST request with a huge file upload to hit this ap_die code and suck in the entire POST request because something has decided that the keepalive state is undecided. It's not undecided, I have told it that it is off and the 403 or 404 is the second big clue. I guess what we are agreeing on here is that the logic that sets keepalive to 0 is faulty and that is probably where the real fix lies. -Rasmus
