httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: AddOutputFilter hook needed?
Date Tue, 19 Sep 2000 09:42:26 GMT
On Tue, 19 Sep 2000, Greg Stein wrote:
> On Mon, Sep 18, 2000 at 09:50:29AM -0700, wrote:
> >...
> > If we are talking about a content based filter, then there are two reasons
> > for the filter to be inserted.  #1, the filter was in an AddOutputFilter
> > directive, so the core takes care of it.  #2 The mime type informs either
> > the core or the module to insert the filter.  It makes more sense to me to
> > have the core doing that, because the core has the mime information and
> > the filter list.  If the core is the thing doing all of the ap_add_filter
> > calls, then we have no issue here.
> Or #3: a module-specific directive enables the insertion of a filter.
> Consider the character set stuff. Some directive named "SpecifyCharSet" says
> what charset the directory/location is in. The module inserts a filter to
> deal with it during the insert_filter phase.
> How about a directive named "SetCompression gzip" ? That inserts a filter
> during the insert_filter phase.

No, they shouldn't use the insert_filters phase.  That's the problem.  All
of those are directive based, they should be inserted immediately after
the request is read, because they are the basis for all of the rest of the
filters, which means that belong in post_read_request.  As it stands right
now, they are inserted just before the request is run, which makes no
logical sense.  It means that even if a module wants to determine if it's
filter has already been added, it really can't, because the filter will
almost always be added after the check occurs.

> > Regardless, the insert_filters hook is bogus and shouldn't be
> > used.  Filters need to be inserted whenever it is determined that the
> > filter is needed.  Having the insert_filters hook doesn't stop that from
> > happening, but it makes it look like all filters need to be added during
> > insert_filters.  Adding a filter during the insert_filters phase is wrong,
> > it should never be done.  Either we have had the information that tells us
> > to insert the filter for a while (in which case the filter should have
> > been inserted as soon as we knew it was necessary), or we don't really
> > know the filter is needed yet (in which case the filter should be inserted
> > as soon as we know it is necessary).  Either way, doing anything in
> > insert_filters is wrong.  This is why I have been arguing to get rid of
> > that hook.  Having it in the server just doesn't make any sense.
> Sorry, but your position is simply untenable. If you look at it from the
> AddOutputFilters directive, and that is *all*, then sure. But that is *way*
> too narrow of a view on filter insertion.
> Modules may specify all kinds of filters and have all kinds of ways to
> insert them. The insert_filters hook is the best place to provide a
> mechanism for just that.
> It should stay.

The funny thing is Greg, I am taking a VERY wide view.  I am saying remove
the hook because it is unnecessary.  Filters can be added at ANY point,
not just some pre-defined point that I added to the server.  This hook is
just unnecessary, it's function can be better served by letting modules
add their filters when it is appropriate.


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

View raw message