On Fri, Sep 28, 2001 at 06:31:57PM -0400, [EMAIL PROTECTED] wrote: >... > Ah... Hate to butt in here but if the Justin's original reason for > rewriting the entire socket input 'front door' was (as he said ) > because of something about it NOT handing client->host > Transfer-encoding very well then I'm not sure it isn't worse off now > than it was before.
The code was to clean up a bunch of problems in the input filtering. There shouldn't be any real functional change (and I didn't see any). However, adding input filters should actually have a chance to work now. > I have been looking and looking at the patch and someone want > to tell me where it checks for TE: which is the only way to > REALLY know how the Transfer-Encoding will end? ( Blank > CR/LF following CR/LF following 0 byte length, or no? ). It did not before, so it doesn't now. For the most part, this is a rearrangement of code. There is a lot of cleanup and rationalization to the code. It should be much easier to fix/extend the code now. > Near as I can tell it just relegates 'extra' CR/LF back to stream > as 'useless noise' instead of actually knowing for sure if it > was a proper end to the Transfer-Encoding. Yup. > Caveat: I have NOT had time to REALLY pour over this HUGE > patch so I may be totally off-base... but I think this fact alone > is what Ryan is trying to explain... there hasn't been enough > TIME to look at this HUGE/CRITICAL patch. It *has* been reviewed. Given that we're in commit-then-review mode, and that two people are fine with the patch, then it can/should go in. If further problems are discovered in the patch, then they can be fixed in the repository rather than before the patch is applied. Cheers, -g -- Greg Stein, http://www.lyra.org/
