Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Tue, 19 Sep 2000 05:48:28 -0700
From: Greg Stein <gstein@lyra.org>
To: new-httpd@apache.org
Subject: Re: AddOutputFilter hook needed?
Message-ID: <20000919054828.C29589@lyra.org>
Mail-Followup-To: new-httpd@apache.org
References: <m3lmwppyeu.fsf@adsl-77-241-65.rdu.bellsouth.net>
 <Pine.LNX.4.21.0009180942300.1200-100000@koj>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <Pine.LNX.4.21.0009180942300.1200-100000@koj>;
 from rbb@covalent.net on Mon, Sep 18, 2000 at 09:50:29AM -0700

On Mon, Sep 18, 2000 at 09:50:29AM -0700, rbb@covalent.net 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.

Or possibly "EnableActiveScripting python, perl, jscript, vbscript" which
goes and loads an ActiveScripting engine and processes output appropriately.
That processor is inserted during the insert_filters hook.

> 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.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/