You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2001/08/30 15:53:25 UTC

Re: cvs commit: httpd-2.0/modules/experimental mod_charset_lite.c

"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:

> Jeff,
> 
>   does this really work?!?  That is, you are looking at the core per-dir-config,
> but the mod_mime and soon other modules have configurable filters.  These entries
> do _not_ go into the core config.

I guess you're telling me that it doesn't work because now there are
more ways to get filters added :)  This would only check filters added
via core directives.  Darn...

>   Perhaps this needs to become a request_rec field, or we need an iterator over
> the configured filters in the core?

I don't think either of those (request_rec field or iterator) would
help my situation.

The logic in question is called from my insert-filter hook, where I
want to insert the appropriate filter if I've been told to perform a
translation.  However, in certain cases the admin has to use a
directive like AddOutputFilter to cause the charset filter to be
inserted at a special location relative to other content filters
(e.g., INCLUDES).  In that case, I don't want my insert-filter hook to
add it again since the core will add it.

I think you're saying that beyond core (whose config I was looking
at), any other modules (e.g., mime) might add a charset filter too
based on their own directives.  And if this is the case, then
obviously my insert-filter hook shouldn't bother checking because
another module could add my filter after my insert-filter hook is
called.  Thus, I have to wait until my filter is called to see if my
implicitly-added filter needs to be removed.

Right?

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

Re: cvs commit: httpd-2.0/modules/experimental mod_charset_lite.c

Posted by Jeff Trawick <tr...@attglobal.net>.
Ryan Bloom <rb...@covalent.net> writes:

> On Thursday 30 August 2001 06:53, Jeff Trawick wrote:
> > I think you're saying that beyond core (whose config I was looking
> > at), any other modules (e.g., mime) might add a charset filter too
> > based on their own directives.  And if this is the case, then
> > obviously my insert-filter hook shouldn't bother checking because
> > another module could add my filter after my insert-filter hook is
> > called.  Thus, I have to wait until my filter is called to see if my
> > implicitly-added filter needs to be removed.
> >
> > Right?
> 
> Or, you could make your insert_filter phase a REALLY_LAST function,
> and walk r->output_filters.

this seems reasonable for the short term; I just don't want to use
REALLY_LAST unless absolutely necessary because sooner or later
somebody else that I need to run after will think they are special and
be REALLY_LAST too (but perhaps this isn't an imminent occurrence :) )

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

Re: cvs commit: httpd-2.0/modules/experimental mod_charset_lite.c

Posted by Ryan Bloom <rb...@covalent.net>.
On Thursday 30 August 2001 06:53, Jeff Trawick wrote:
> "William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> > Jeff,
> >
> >   does this really work?!?  That is, you are looking at the core
> > per-dir-config, but the mod_mime and soon other modules have configurable
> > filters.  These entries do _not_ go into the core config.
>
> I guess you're telling me that it doesn't work because now there are
> more ways to get filters added :)  This would only check filters added
> via core directives.  Darn...
>
> >   Perhaps this needs to become a request_rec field, or we need an
> > iterator over the configured filters in the core?
>
> I don't think either of those (request_rec field or iterator) would
> help my situation.
>
> The logic in question is called from my insert-filter hook, where I
> want to insert the appropriate filter if I've been told to perform a
> translation.  However, in certain cases the admin has to use a
> directive like AddOutputFilter to cause the charset filter to be
> inserted at a special location relative to other content filters
> (e.g., INCLUDES).  In that case, I don't want my insert-filter hook to
> add it again since the core will add it.
>
> I think you're saying that beyond core (whose config I was looking
> at), any other modules (e.g., mime) might add a charset filter too
> based on their own directives.  And if this is the case, then
> obviously my insert-filter hook shouldn't bother checking because
> another module could add my filter after my insert-filter hook is
> called.  Thus, I have to wait until my filter is called to see if my
> implicitly-added filter needs to be removed.
>
> Right?

Or, you could make your insert_filter phase a REALLY_LAST function,
and walk r->output_filters.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------