You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by tr...@apache.org on 2001/08/30 14:29:37 UTC
cvs commit: httpd-2.0/modules/experimental mod_charset_lite.c
trawick 01/08/30 05:29:37
Modified: modules/experimental mod_charset_lite.c
Log:
since the core now stores the input and output filter lists in a
different format, mod_charset_lite needs different logic to walk
through it
Revision Changes Path
1.49 +18 -14 httpd-2.0/modules/experimental/mod_charset_lite.c
Index: mod_charset_lite.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_charset_lite.c,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- mod_charset_lite.c 2001/08/07 16:19:02 1.48
+++ mod_charset_lite.c 2001/08/30 12:29:37 1.49
@@ -373,34 +373,38 @@
return DECLINED;
}
+static int configured_in_list(request_rec *r, const char *filter_name,
+ const char *filter_list)
+{
+ const char *filter;
+
+ if (filter_list) {
+ while ((filter = ap_getword(r->pool, &filter_list, ';')) && filter[0]) {
+ /* yeah, I'm an ass and expect them to type it correctly (all caps)
+ */
+ if (!strcmp(filter, filter_name))
+ return 1;
+ }
+ }
+ return 0;
+}
+
static int configured_on_input(request_rec *r, const char *filter_name)
{
- int i;
core_dir_config *conf =
(core_dir_config *)ap_get_module_config(r->per_dir_config,
&core_module);
- char **items = (char **)conf->input_filters->elts;
- for (i = 0; i < conf->input_filters->nelts; i++) {
- if (!strcmp(items[i], filter_name))
- return 1;
- }
- return 0;
+ return configured_in_list(r, filter_name, conf->input_filters);
}
static int configured_on_output(request_rec *r, const char *filter_name)
{
- int i;
core_dir_config *conf =
(core_dir_config *)ap_get_module_config(r->per_dir_config,
&core_module);
- char **items = (char **)conf->output_filters->elts;
- for (i = 0; i < conf->output_filters->nelts; i++) {
- if (!strcmp(items[i], filter_name))
- return 1;
- }
- return 0;
+ return configured_in_list(r, filter_name, conf->output_filters);
}
/* xlate_insert_filter() is a filter hook which decides whether or not
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
--------------------------------------------------------------
Re: cvs commit: httpd-2.0/modules/experimental mod_charset_lite.c
Posted by Jeff Trawick <tr...@attglobal.net>.
"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...