> > > Installing a filter that deals strictly with body data can be done
> during
> > > the insert_filter phase. This is where output filters are commonly
> > > inserted into the chain. Since this is always called before the handler
> > > phase, we are alright.
> >
> > This doesn't work - the filter is inserted, but it never runs.
>
> Read Ryan's response carefully (and my earlier responses this AM). The
> input filter can filter the request body (not headers).
>
> >
> > > This logically makes sense, because modules that
> > > handle request body data do so by calling ap_get_client_block in the
> > > handler phase. So, as long as the input filter is inserted before the
> > > handler is called everything is okay.
> > >
> > > Exactly what are you trying to do, and how is it not working?
> >
> > If you use ap_add_input_filter() inside the ap_hook_insert_filter() hook
> > the filter doesn't run ever.
> >
> > The HeaderIn directive allows you to add or alter incoming headers
> > before they are sent to modules like mod_proxy or mod_cgi.
>
> As I (and now Ryan) have pointed out, the only way to filter headers is to
> hook the pre_connection hook. But this is a really bad idea for reasons
> mentioned in both of our previous posts. I think the right thing to do with
> mod_headers is to handle the HeaderIn processing in the request fixup hook,
> not as a filter.
Why is this a bad idea? The filter should be able to determine if it is
required very quickly, and if it isn't, it just removes itself. If it is,
then it just does it's job.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
