On Wed, 9 Jun 2004, Jim Jagielski wrote:
On Jun 9, 2004, at 3:24 PM, Rasmus Lerdorf wrote:
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.
yeah... it's pretty inconsistent. Looking at ap_set_keepalive
I had sent private Email to your @apache.org address
(since that's the one you use to provide HTTPD related
patches).
On Jun 8, 2004, at 5:10 PM, Rasmus Lerdorf wrote:
Uh, I never received anything on this. Did you actually send me
something? I'll have a look at addressing this issue. Releasing
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
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
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
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
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,
On Jun 9, 2004, at 3:24 PM, Rasmus Lerdorf wrote:
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.
yeah... it's pretty inconsistent. Looking at ap_set_keepalive
even after we know the connection will be
William A. Rowe, Jr. wrote:
At 07:09 AM 5/28/2004, Jim Jagielski wrote:
I've backed out that patch and asked Rasmus to send a replacemnet
which addresses his specific problem but does not cause
the below behavior.
I'm tempted to release 1.3.32...
Collect another week or few of data on
Jeff Trawick wrote:
This patch did it:
http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_request.c?r1=1.173r2=1.174
Backing out the patch also fixes a DAV regression. See
http://issues.apache.org/bugzilla/show_bug.cgi?id=29237
See also
On Fri, May 28, 2004 at 06:14:30AM -0400, Jeff Trawick wrote:
Jeff Trawick wrote:
This patch did it:
http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_request.c?r1=1.173r2=1.174
Backing out the patch also fixes a DAV regression. See
Hmm.. this was a patch suggested by Rasmus, iirc.
Jeff Trawick wrote:
Jeff Trawick wrote:
This patch did it:
http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_request.c?r1=1.173r2=1.174
Backing out the patch also fixes a DAV regression. See
I've backed out that patch and asked Rasmus to send a replacemnet
which addresses his specific problem but does not cause
the below behavior.
I'm tempted to release 1.3.32...
Jeff Trawick wrote:
This patch did it:
At 07:09 AM 5/28/2004, Jim Jagielski wrote:
I've backed out that patch and asked Rasmus to send a replacemnet
which addresses his specific problem but does not cause
the below behavior.
I'm tempted to release 1.3.32...
Collect another week or few of data on other problems first, perhaps?
Once
This patch did it:
http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_request.c?r1=1.173r2=1.174
See also
http://issues.apache.org/bugzilla/show_bug.cgi?id=29257
http://www.rtr.com/fp2002disc/_disc2/0a71.htm
15 matches
Mail list logo
