httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Tag time?
Date Mon, 01 Oct 2001 12:49:14 GMT

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.



View raw message