--On Tuesday, October 26, 2004 12:03 PM -0400 Greg Ames <[EMAIL PROTECTED]> wrote:
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.
right, I understand. check_pipeline_flush already tests whether the input filters hold any data if I'm not mistaken.
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.
not if we modify it so that the worker thread doesn't give up the connection to the event thread when there is more data in the input filters. That's what I meant by "react appropriately". Sorry if I wasn't clear.
Greg
