httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: Event MPM
Date Tue, 26 Oct 2004 16:31:04 GMT
--On Tuesday, October 26, 2004 12:03 PM -0400 Greg Ames <> 

> Yes, this needs to be fixed.  I don't see it as difficult problem.  We
> already test for whether the output filters need to be flushed (i.e., is
> there any more data in the input filter chain) before the request ends.  We
> just need need to remember the outcome of that test and react appropriately.

This isn't about whether the output filters need to be flushed: this is about 
whether the connection-level input filters have already read data from the 
socket and are hanging onto data that needs to be processed before the client 
will send more data.  The event MPM will be sitting on a poll() waiting for 
the client to send more data when the client already has sent the next request.

> Are there a lot of browsers out there that implement true pipelining?  I
> know it's in the RFC for good reasons but I don't believe I've ever seen it
> in the wild.

Mozilla, Opera, Squid, etc.  I'm, uh, absolutely against any code being 
checked in that breaks HTTP pipelining.  (You should get the drift of where 
I'm going.)

> umm, I disagree.  I'm not too concerned about worker threads blocking in
> socket reads occasionally.  The point here is to go after the low hanging
> fruit (frequent long delays between requests) without massive code churn in
> the server.

Certainly not at the expense of HTTP/1.1-compliance.  -- justin

View raw message