httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: cvs commit: apache-2.0/src/main http_core.c
Date Tue, 10 Oct 2000 03:46:54 GMT writes:

> > If this code is really supposed to look for LF, what the heck is the
> > code in http_filter() for?  That code seems perfectly capable of
> > finding the end of a header line.  In addition, it even knows when it
> > is valid to think in terms of header lines (excusing the possibility
> > of chunked encoding for the moment).
> But, it can't buffer data.  The whole point of this section of code, is to
> buffer for those apps that send a char at a time.

That code is broken.

> > 
> > core_input_filter() doesn't know the difference between header and
> > body.  As such, it can't look for LF.
> Without this change, telnet apps that send a char at a time won't
> work.  It's that simple.  Since this is basically the exact same design
> that 1.3's BUFF code used, I think we are safe.

Not a chance is it the same as 1.3.  

> The removal is bogus.  It breaks Windows and BeOS, and it MUST be
> reversed.

Let's see... In several lines of code I show you a storage overlay and
a place where you're looking for a LF in the request body and you say
the removal is bogus and that it is basically the exact same design as
1.3's BUFF code?  That's almost funny :)

core_input_filter() was broken for the reasons stated...  Let's move

I'm trying to understand why is it so important that the code to
ensure that we have a LF lives in core_input_filter().  It seems that
we already have enough code that knows what a header line looks like
(http_filter(), and getline() to a lesser extent).  

Why not have http_filter() ask for another brigade if it doesn't get
enough data back?  Otherwise, core_input_filter() is going to have to
know whether it is in header mode or body mode.

Jeff Trawick | | PGP public key at web site:
          Born in Roswell... married an alien...

View raw message