httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: cvs commit: apache-2.0/src/main http_connection.c http_core.c http_protocol.c http_request.c util_filter.c
Date Thu, 05 Oct 2000 19:12:27 GMT wrote:

> > What about the request body (and maybe even the header of the next
> > request) in the same buffer read by CORE_IN (or SSL)?
> >
> >   It doesn't matter that the request body is in the same packet as the
> >   request headers.  CORE_IN and getline() have to work together so that
> >   any data after the header is made available to CORE_IN for the next
> >   time it is called.
> >
> >   getline() is called repeatably to grab the request line and header
> >   fields.  It only cares about the conn_rec filters.  When it gets to
> >   the end of the header any unparsed data must be chained back on the
> >   conn_rec for CORE_IN (or SSL) to access again.
> All of this assumes that CORE_IN has some understanding of HTTP, it
> doesn't, and it shouldn't.  The whole point of CORE_IN, is that it only
> understands reading from the network.

CORE_IN doesn't need to know about HTTP.  Having it only understand network
stuff and bucket brigades is perfect.  But it needs to co-operate with the
protocol code above it that does know about HTTP.  getline()'s callers know
when header lines are expected, and getline() has to be able to logically
extract just one line and nothing more.  But there will be other code for
uploads that will need to get data from CORE_IN.  

The code that separates headers from request bodies worked last week (I
think :-); we have enough Smart People (tm) hanging out on this list to get
it working again if it's currently broken.  So if we can separate inbound
headers from request bodies, why not let the request bodies flow thru
inbound content filters if somebody wants to do that?


View raw message