In a message dated 01-10-01 04:37:59 EDT, Greg Stein wrote...
> > 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. Ah... Okay. I will stop looking for what isn't there, then. > > 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. Actually... on further inspection... turns out this is a 'good' thing. If you are not actually stopping to find out for SURE if a client is going to be ending Transfer-Encoding with a blank CR/LF then you MUST have some kind of 'noise filter'. See other messages regarding the Netscape 'out of band' CR/LF on POST potentially 'following' blank CR/LF to end trailers. Turns out that no matter what you do there may always be times when a blank CR/LF is to be considered 'line noise' and needs to be tossed by the front-end if it appears before the start of a new HTTP request. The only worst-case scenario is if you treat an 'out of nowhere' CR/LF as a valid request with no valid headers appearing before it. While it is possible to 'know' if there will be a blank CR/LF to indicate 'End of trailers' it's impossible to tell if you are really ever going to get the Netscape 'out of band' CR/LF. Might be stripped by a Proxy, might not, but it's never part of Content-Length so no way to anticipate it. > > 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. Roger that. Commit away, then. Yours... Kevin
