httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Request Body Filters..
Date Thu, 02 Nov 2000 22:03:35 GMT
Stepping into the middle of this / catching up ...

If a module wants to write their own input filter, then they cannot use
ap_*_client_block(). That occurs outside the filter chain -- they are
utility functions used by request handlers.

Hrm. Is it possible for an input filter to reside between the DECHUNK filter
and the top of the input chain (e.g ap_*_client_block). It looks a bit shaky
given that the input body processing isn't handled entirely within the input
filter chain.


On Mon, Oct 30, 2000 at 05:30:44AM -0800, wrote:
> On Mon, 30 Oct 2000, Sascha Schumann wrote:
> > > This is exactly what request-level input filters are designed for.  There
> > > is no reason to separate the filter types more, because a connection based
> > > input filter sees both headers and body data, but a request based filter
> > > sees only body data, especially if it is after the chunking filter.
> > 
> >     Right. So we just need something in default_handler which
> >     triggers the input filters.
> No, that is the wrong concept of input filters.  Your module's input
> filters will be called for the data by ANY handler, not just the default
> handler.  The only thing that needs to be done, is to allow the handler to
> understand how to read data from ap_get_client_block.  Your module can
> intercept that data just by putting itself in the filter stream.
> I have reviewed the patch a little bit, but I need to look at it in much
> more depth.  It is FAR too complex though.  All that should be required is
> something along the lines of:
>     if (method_allows_body(r->method)) {
>         ap_setup_client_block()
>         while (ap_get_client_block()) {
>         }
>     }
> This allows all modules that implement an input filter to see the data
> that is sent as a part of the body (PHP could keep a copy of it if they
> want to, or maybe it should be a part of the request).
> We do not need or want a third filter type.  There are input and output
> filters, and that is all that should be needed.  Hopefully I will be able
> to review in more detail later today.
> Ryan
> _______________________________________________________________________________
> Ryan Bloom               
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------

Greg Stein,

View raw message