httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: cvs commit: apache-2.0/src/main http_protocol.c
Date Thu, 12 Oct 2000 15:23:47 GMT
On Thu, Oct 12, 2000 at 06:43:01AM -0700, wrote:
> > But how does this work in the presence of chunking?
> > 
> > Let's presume that the input-chunking-filter sits above http_filter. To read
> > a chunk from the body, it must do a getline(). Then, it must read N bytes of
> > data. Then, it will do a getline() again.
> > 
> > c->remaining does not signal "end of request", but just "end of read".
> > Another flag must be used to signal end-of-request (as I stated in my
> > commentary email).
> > 
> > Hmm... also, it sounds like we ought to have a utility function that reads a
> > line of text from a brigade. That can be used by the header-reading code,
> > and by the chunk-handling code.
> No.  chunking works, because the de-chunk filter sits in a loop.  It reads
> a line using c->remaining == 0, then it reads a block of data.  Then it
> reads a line (c->remaining == 0), then it reads a block of data,
> etc.  There is no need to signal end of request.  We are at the end of the
> request when the de-chunk filter stops reading, and it sets c->remaining
> to zero.

Hmm. I'm not entirely agreeable with your description above. However, we're
about to torch c->remaining, so I'm thinking a new plan is in order anyways.

Oh boy. This doesn't feel quite right. The chunk_filter is managing the
operation of the http_filter through some variable stored in conn_rec. I'm
not sure of a way out of it because http_filter should never be allowed to
read past the end of a request (if it did, then the chunk_filter could end
up with input for the next request which might not be chunked(!)). But
http_filter has two states: read a line (but no more!), and read raw data.

Reading a line does imply a scan for CR/LF chars, so I'm feeling better
about having that in http_filter. Not sure that we should munge them there.
That whole "reach into the bucket and tweak it" just feels wrong. I'd rather
see getline() do that.

Hmm. getline() will be practically a no-op. Since we have to be so careful
in http_filter, that implies http_filter will return exactly one line (or it
will signal that the line is larger than the specified size). getline() can
just map the brigade returned from http_filter into a buffer and be done
with it. getline() will loop across the buckets and memcpy them into the

[ hey... it looks like neither 1.3 nor 2.0 has getline() failing if the line
  exceeds the buffer length. that doesn't seem right. success would imply
  that the "next line" would be the tail of the excessive line. ]


Greg Stein,

View raw message