I was taking a look at the implementation of the renamed (but still misleading) AP_MODE_EATCRLF,
AP_MODE_PEEK was more accurate, but whatever...
Removing the mode altogether would mean that either every request was flushed through the filter chain even in pipelining mode, or that ap_process_request would have to come up with some other way of detecting pending input. Unless there is good empirical evidence of the pipelined filter flush leading to performance problems, the first of these options would seem attractive.
I vote for something like your second option but ap_process_request shouldn't be involved.
the reason that this and the corresponding 1.3 BUFF logic exists is to minimize "tinygrams" - ip packets that are less than a full mtu size. tinygrams definately degrade network performance and trigger things like Nagle's algorithm. in this particular case we are trying to combine response data from two or more different pipelined requests into a single packet.
however our post-filters implementation is very costly in terms of cpu. we make an extra trip down both filter chains. on the first trip down the output filter chain we are almost ready to call apr to transmit the data when the core output filter stashes the output data, temporarily abandons it, and unwinds. then we go down the input filter chain with AP_MODE_EAT_CRLF to see if there is more input data stashed (and do an extra socket read() syscall that doesn't happen in 1.3). assuming the answer is no (typical) we send a flush bucket down the output filter chain, get back to the core output filter, encounter numerous cache misses reading all the instructions and data back into the cpu caches to pick up where we left off, then finally hand off the response data to the apr socket functions.
what I'd like to see instead is for the input filter chain to keep track of whether there is any stashed input any time it is called. then the core output filter could do a simple check on the first trip down the output filter chain to see whether it's ok to transmit. the downside is that we may have accumulated extra baggage that is dependent on AP_MODE_EAT_CRLF or flush buckets, so this change would definately need to wait for a version boundary. in the mean time we should avoid adding any new function dependent on AP_MODE_EAT_CRLF or standalone flush buckets.
Greg
