Some comments:
1) The loop in server/core_filters.c:226
while (c < str + len) {
if (*c == APR_ASCII_LF)
c++;
else if (*c == APR_ASCII_CR && *(c + 1) == APR_ASCII_LF)
c += 2;
else
return APR_SUCCESS;
}If the last character of the bucket being examined is an ASCII CR, this will first look beyond the end of the bucket's buffer to check for an LF; assuming it doesn't find one in the random byte it looks at, it will then return APR_SUCCESS even if the following bucket (if any) started with an LF. So that's presumably wrong on two counts.
2) The only place I can see that this mode is actually used is in modules/http/http_request.c, where it is used to decide whether or not to flush the filter chain before logging. the comment at line 226 of that file seems reasonable:
/*
* We want to flush the last packet if this isn't a pipelining connection
* *before* we start into logging. Suppose that the logging causes a DNS
* lookup to occur, which may have a high latency. If we hold off on
* this packet, then it'll appear like the link is stalled when really
* it's the application that's stalled.
*/
Presumably that's true whether or not the connection is pipelining; why is it acceptable to make a link appeared stalled in a pipelining connection but not a keepalive connection?
3) In general, AP_MODE_EATCRLF seems to me to be a tight coupling between a particular function in http_request.c and a particular input filter (core_input_filter). The expense is added complexity for every input filter.
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 presume the main reason to avoid flushing between pipelined requests would be a sequence of WebDAV requests with short responses, although there is also the common case of browsers pipelining a request for favicon.ico before the page actually requested by the user. But are the responses so short that the flush would have an enormous impact? The favicon.ico response from a random iconless server comes out at 458 bytes, for example.
