httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [PATCH] ap_add_filter
Date Fri, 18 Aug 2000 00:42:47 GMT
On Thu, Aug 17, 2000 at 04:52:45PM -0700, wrote:
> The insert_filter thing is wrong.  Most modules won't be using it, because
> it can only deal with those things that are determined in the config
> file.  That is what I am trying to get across here.  We are wrong
> currently.

This is where we disagree. I feel the insert_filter is very useful. It runs
well after all the header parsing, auth checks, translation, type check and
setup, etc. It has a ton of information available to it. It runs *just*
before the content handler.

Therefore, the only information that it doesn't have is the data produced by
the content handler.

insert_filter should even have content-type information because that should
be set up well before the content handler produces it (e.g. mod_mime).

> > Summary: can we add the "next" stuff and defer the prepend/append thing
> > until we have more experience with actual filters?
> > 
> > IOW: -1 on the prepend/append. +1 on the "next" param to add_filter.
> That doesn't solve the current problem.  Here's the way I see it.  We have
> something that doesn't work, that we designed before ever having any
> experience with actually writing filters.  And, we have another solution
> that does work, and is based on the experience of writing a filter.  One

Write *a* filter. I think it is still a bit premature to alter the design
(we checked this stuff in back in June; after a lot of thought about how
filters would be inserted; it has been well-cooked for a while)

> of the people supporting the new method (Roy) has more experience with
> filters in general, AFAIK.

Filters in *Apache*? We have a rather non-deterministic code base here.
Stuff can happen here, there, everywhere. At many different points, by many
different modules. I do not believe that Apache can support the ideal
situation for dealing with filter insertion. Our compensation for that is
the filter types/groups.

> What is the argument for not switching now, and avoiding releasing an
> alpha with a serious hack that won't work for any module other than
> chunking?

We don't have a hack. The "+1" on the filter type was the smallest change
towards what I believe is the proper change: add AP_FTYPE_NETWORK. But until
that received an okay, I didn't want to go that far.

Creating a reversed sense on filter insertion, thus making the insert_filter
hook rather useless is not right. I also think most of the content filters
will want the append-style. Also, reversing the sense of the test simply
reverses the class of problems that we run into. Some filters want a prepend
style, some want an append style.

What we have works well, and can be released as part of an alpha. It is not
a hack.


Greg Stein,

View raw message