--On Tuesday, October 26, 2004 4:25 PM -0400 Greg Ames
that sucks IMO, but it does sounds like how the code works today. We do socket read() syscalls during the MODE_EATCRLF calls that are almost always unproductive. They could be optimized away. I don't believe 1.3 does these extra read()s.
1.3 does it in reverse: it discards the extra CRLFs at the beginning of the request lines. Hmmmmm. Looking at the code, httpd-2.x does the same thing in read_request_line. So, we could probably toss the EATCRLF mode entirely without any ill effects. It's kind of pointless...
IIRC we invented MODE_PEEK (MOD_CRLF's ancestor for the newbies) so we could pack response bodies for true pipelined requests into the minimum number of network packets. The idea was bypass the network flush if there is more input data to optimize throughput. It's a great idea high level, but we burn too many cycles implementing the check in the common case.
So I'm thinking that we should see MODE_EATCRLF behave differently when core_input_filter has data stashed.
Greg
