Re: Time for 1.3.32 ?

[Jim Jagielski <ji...@jaguNET.com>]

I'm reviewing this... I'm mostly investigating whether
the check for keepalive!=1 before calling ap_set_keepalive
in ap_send_http_header and ap_send_error_response is
too ap_die() specific. It seems to me that
ap_set_keepalive should be smarter internally about
"double or more calls" per request.

Re: Time for 1.3.32 ?

[Rasmus Lerdorf <ra...@apache.org>]

On Fri, 20 Aug 2004, Jim Jagielski wrote:
> I'm reviewing this... I'm mostly investigating whether
> the check for keepalive!=1 before calling ap_set_keepalive
> in ap_send_http_header and ap_send_error_response is
> too ap_die() specific. It seems to me that
> ap_set_keepalive should be smarter internally about
> "double or more calls" per request.

Yup, it should.  I tried to minimize the amount of code I touched to fix
the problem at hand.

The keepalive!=1 check prevents double-counting the request in the
keepalive counter.  if keepalive!=1 we know that either ap_set_keepalive()
has not been called yet, or it has been called and keepalive is off, so in
either case we won't be double-counting the request.

I still think the real problem is two-fold:

 1. ap_set_keepalive() is called way too late in the request

 2. it is impossible to tell if r->connection->keepalive has
    been set since 0 can both mean it hasn't been set and that
    it has been set and keepalive is off

My fix/hack just forces ap_set_keepalive to be called earlier on an
ap_die() request and then I try to make sure that the subsequent calls
won't double-increment the keepalive counter.

If ap_set_keepalive() was fixed to be immune to being called twice during
a request then those keepalive!=1 checks can be removed.

-Rasmus