Justin Erenkrantz wrote:
I was able to easily create a browser hang by configuring Mozilla to enable HTTP pipelining, then pointing my DocumentRoot at an old copy of the xml.apache.org web site which had tons of imbedded graphics. Thanks, Justin, for pointing out the bug.
I'm sure you *really* want to thank me for pointing this out. ;-)
Actually I am, because I'm pretty pleased with what Bill S, Paul & I have done already. Fixing this bug makes it more stable.
Okay. I'd be curious to figure out what's going on with the speculative non-blocking reads. I think that's the conceptually right solution (or as close as we can do today), but I'm almost positive there is going to be something that barf on it - so we'd have to fix some stuff. So, I'm not shocked that it doesn't quite work...
The odd behavior with speculative reads is due to API differences that I didn't take into account. EATCRLF returns APR_EOF when there is no input; SPECULATIVE returns APR_SUCCESS and (presumably) an empty brigade. So the pipeline didn't get flushed when it should and the connection tied up a worker thread until read_request_line timed out. It shouldn't be difficult to patch when I get a little time (the hard part).
Glancing at core_input_filter, it wasn't clear how SPECULATIVE was going to be an improvement. I saw socket bucket reads in my test environment (no mod_ssl) with both modes.
I think Paul's already posted a patch that folds it in. But, it still uses EATCRLF.
Given the timeframe and the fact that my schedule just sucks for the next two weeks, is there enough interest (and presence) to discuss this at the Hackathon next weekend in LV?
wish I could be there physically, but I can't :( Maybe IRC?
Greg
