httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
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:41:54 GMT

> > 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.  

We're not communicating here.  There is no such concept as an input
request header currently.  It is not currently possible.  The reason for
this, is that the CORE_IN filter returns a chunk of data to
getline.  Getline parses it for a single line and saves the rest off to
the side.  That's how it currently works.  Getline isn't really a filter,
it is more analogous to a handler.

Later, when ap_get_client_block is called, it doesn't call getline.  It
will need to go either straight to the conn_rec, or it will have to call
ap_get_brigade.  Currently, if a body is sent with a request, it is likely
to be stored in the conn_rec.  This means that the data has already been
filtered.  It can't be filtered again, because it was filtered once when
the request was originally read.  There is no way currently for a request
body to go throught request input filters.

The only solution, is to have a filter that understands HTTP, and that can
break the brigade into multiple pieces of headers and bodies.  This filter
would keep a buffer of the input data until it was requested to give it to
the core.  This isn't in place, so there is no such thing as an input
request filter.  This doesn't even make sense to put into place until
ap_get_client block is finished (which I'm currently working on).

> 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?

It's broken, because we added filtering.  This isn't a question of Smart
People (tm), it's a question of design.  input and output filters are not
orthogonal.  They can't be orthogonal, because the design doesn't allow
it.  Trying to pretend that they are is a mistake.

A new input content filter cannot be added between the call to
ap_get_brigade and the time that it returns.  input filters cannot be
removed between the call to ap_get_brigade and the time that it
returns.  Both of these limitations do not exist with output filters.  I
am trying to stress the fact that input and output filters do NOT work the
same way in this server.  The commit I am questioning makes them look very
similar on the surface, even though they are fundamentally different.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message