httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: dev question: apreq 2 as a filter?
Date Mon, 26 Aug 2002 14:13:45 GMT
At 03:09 AM 8/26/2002, Issac Goldstand wrote:

> > The things that I see weird about this is that the normal filter is not
> > supposed to call ap_get_brigade more than once. our apreq_ filter calls
> > ap_get_brigade more than once, because if it doesn't, there is no way to
> > consume the data (the response handler) will usually not ask for the raw
> > body. So apreq_ is really a semi-filter, since it acts as a filter and
> > consumer at the same time.
>
>Not necessarily.  My example from yesterday proposed two distinct operating
>"modes"; one which will do this, and the other default one, which will not.

Note that all handlers are required to consume the post body.  The dev@httpd
list already had to pound through that issue more than once.  This should
assure we are safe.

In the end-game, there will be a very limited number of 'handlers'.  The 
handler
to serve filesystem documents, a handler to generate autoindexes, handlers
to serve data from SQL or .tar.gz content warehouses, etc.  For the most part,
many 'handlers' today are really filters around a data store.  Those cases
should become true filters, then we have a very limited number of real handlers
to enforce a given behavior upon.

If that behavior is that the client must read the body, then that is the 
rule.
In the general case today, this apreq input filter needs to be smart enough
to read and set aside the input until the handler is willing to consume it.

Bill



Mime
View raw message