httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [PATCH] ap_add_filter
Date Fri, 18 Aug 2000 22:17:14 GMT

> > > Could you please give an example of such a filter?
> A contrived one given a couple of minutes of thought but:
> you have a running PHP script. It has been told to #include (or
> whatever the PHP equivalent is) another PHP script. But that script
> happens to be gzipped.
> But, I didn't actually mean to say what I said, even though it's true. :)
> I meant to say that there are cases where a filter wants to insert
> itself both at the beginning and end of the list of filters that it
> adds to the chain. The design I propose handles all of these cases by
> giving a filter complete and arbitrary control over its personal
> filter chain.

But that is perfectly possible without all of this.  For example:
if PHP_Filter had the following in it:


And we had the filter stack


After PHP_filter was called, we would get:


> > constructor {
> >     me->filter_chain_head = me->filter_func_impl;
> >     me->filter_chain_tail = me->filter_func_impl;
> > }
> > 
> > me->filter_func() { // this is the filter->write() function, right?
> >     me->filter_chain_head();
> > }
> Note that this is the only new code that a filter needs to have. The
> other functions I listed were just common linked list functions that
> we will include anyway.

This function doesn't make sense.  The filter_func field is the filter
function, i.e. chunk_filter or core_filter/

I would actually think the code would look more like:

ap_filter_t has an ap_filter_t *sublist added to it.

ap_pass_brigade is what calls the next filter, but it is passed the next
filter, not the current one, so every module would need:

if (current_filter->sublist)
    ap_pass_brigade(current_filter->sublist, brigade)
   ap_pass_brigade(current_filter->next, brigade)

Then pass_brigade would need to be modified to not return an error when
the current filter is NULL, instead it would have to walk back up the list
until it found the first filter in the sub_list, and go to that filter's
parent, and call the next filter.  In general a very ugly piece of code,
for no benefit.

The stack mechanism allows for all of this flexability.  The only thing it
doesn't allow for easily is:




but, nobody has come up with a case where that would be useful.

> > Well, if this can be avoided with very simple code, I'd just as soon
> > avoid it.
> The reasons I want to avoid this are the principles of information
> hiding and touch-as-little-as-possible. With a very small amount of
> added code and some slightly changed procedures, you end up completely
> isolating a filter's operations from the main filter chain completely.
> The top-level filter chain can be "owned" completely by the main
> server, and never changed throughout a request. That's just nice. :)

Unfortunately, the design is incredibly ugly to avoid all of those things
in C.  It is possible, but it isn't clean at all.

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

View raw message