httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: AddOutputFilter hook needed?
Date Mon, 18 Sep 2000 20:46:41 GMT
rbb@covalent.net writes:

> On 18 Sep 2000, Jeff Trawick wrote:
> 
> > rbb@covalent.net writes:
> > 
> > > This is unnecessary.
> > > 
> > > On Fri, 15 Sep 2000, Jeff Trawick wrote:
> > > 
> > > > Suppose that if a filter is specified in AddOutputFilter, a hook is
> > > > called (before the insert_filter hook) to tell the module that the
> > > > hook will be added.  Any AddOutputFilter parameter string/tokens would
> > > > be passed to the hook.
> > > > 
> > > > This hook would give the module the opportunity to 
> > > > 
> > > > a) note that it must avoid calling ap_add_filter() itself during the
> > > >    insert_filter hook
> > > 
> > > First of all, the insert_filters stuff hook is
> > > bogus.  Doing anything to try to work around the bogusness of
> > > insert_filters is wrong.
> > 
> > O.k., but how does problem a) get solved?
> 
> Problem a) is a non-issue.  Really think this through.  If this is a
> connection based filter, like charset translation, then the core something
> has to happen to trigger the filter to be inserted.  This is usually a
> header variable, like the chunking filter uses.
> 
> 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.
> 
> 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.
> 

Let's ignore for a moment the particular hook where the module's ap_add_filter()
call is coded. 

Let's say that a module implements logic to decide to insert a filter
during some other hook.  When the module is configured to perform a
certain operation, its filter must be inserted.  If there is an
AddOutputFilter statement, the module is happy to stay out of mucking
with the filter chain.  If there is no AddOutputFilter statement, the
module wants to call ap_add_filter() to insert the filter.  Otherwise,
the module can't possibly perform the requested operation.

How does the module know that there is an AddOutputFilter directive
and that the module should not add its filter implicitly?

If the module doesn't need to know, how do we keep the filter from
being added more than once?  (AddOutputFilter processing could
supercede any ap_add_filter() calls from modules.) 

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message