On 15-Apr-05, at 11:06 AM, Justin Erenkrantz wrote:
The problem with this code is that it'll only read 8 characters worth of
CRLFs. We'd probably want to retry the reads until we don't get more CRLF
pairs. It's not determinate how many extra CRLFs we will get.
Are there browsers which send more than four extraneous CRLF's but still support keepalive?
If this code reads four CRLF's without finding any data, it will assume that there is no immediate incoming request, and send a flush down the filter chain. That does no harm aside from wasting some cycles; on the assumption that the number of cycles wasted is not that enormous and the number of browsers which exhibit that particular behaviour is not huge, I'd say it's not really worth completely retrying the read.
I believe that the current code may exhibit the opposite behaviour: it can falsely report that data is present and thereby omit the flush with the result that a response is not terminated until the following request. If the connection is not being pipelined, the following request is unlikely to show up until the response is terminated, so that would lead to a request which stalls very near to the end. I believe I may have actually seen this symptom in real life, now that I think about it.
So, yes, I'd be fine with removing EATCRLF for 2.2 if you provide a tested
patch. ;-) -- justin
OK, I'll start by at least compiling and testing what I posted.
