Removing AddOutputFilterByType
AddOutputFilterByType has always been problematic. I see there's another bug
report this month arising from it:
http://issues.apache.org/bugzilla/show_bug.cgi?id=33499
Since the purpose of this directive is now available from mod_filter, does
anyone object if I simply yank AddOutputFilterByType from 2.1?
I've hacked a quick patch just to remove it. If people are happy with it,
I'll test it and commit, and add a note to the docs about replacing it.
--
Nick Kew
--- modules/http/http_protocol.c2005-05-17 01:34:36.198019832 +0100
+++ modules/http/http_protocol.c.new2005-06-19 17:16:34.072088128 +0100
@@ -817,13 +817,6 @@
}
else if (!r-content_type || strcmp(r-content_type, ct)) {
r-content_type = ct;
-
-/* Insert filters requested by the AddOutputFiltersByType
- * configuration directive. Content-type filters must be
- * inserted after the content handlers have run because
- * only then, do we reliably know the content-type.
- */
-ap_add_output_filters_by_type(r);
}
}
--- include/http_core.h 2005-06-19 17:18:46.674929432 +0100
+++ include/http_core.h.new 2005-06-19 17:19:03.620353336 +0100
@@ -553,9 +553,6 @@
apr_table_t *accf_map;
} core_server_config;
-/* for AddOutputFiltersByType in core.c */
-void ap_add_output_filters_by_type(request_rec *r);
-
/* for http_config.c */
void ap_core_reorder_directories(apr_pool_t *, server_rec *);
--- server/core.c 2005-06-19 17:14:18.424709664 +0100
+++ server/core.c.new 2005-06-19 17:22:00.421475480 +0100
@@ -163,60 +163,6 @@
return (void *)conf;
}
-/*
- * Overlay one hash table of ct_output_filters onto another
- */
-static void *merge_ct_filters(apr_pool_t *p,
- const void *key,
- apr_ssize_t klen,
- const void *overlay_val,
- const void *base_val,
- const void *data)
-{
-ap_filter_rec_t *cur;
-const ap_filter_rec_t *overlay_info = (const ap_filter_rec_t *)overlay_val;
-const ap_filter_rec_t *base_info = (const ap_filter_rec_t *)base_val;
-
-cur = NULL;
-
-while (overlay_info) {
-ap_filter_rec_t *new;
-
-new = apr_pcalloc(p, sizeof(ap_filter_rec_t));
-new-name = apr_pstrdup(p, overlay_info-name);
-new-next = cur;
-cur = new;
-overlay_info = overlay_info-next;
-}
-
-while (base_info) {
-ap_filter_rec_t *f;
-int found = 0;
-
-/* We can't have dups. */
-f = cur;
-while (f) {
-if (!strcasecmp(base_info-name, f-name)) {
-found = 1;
-break;
-}
-
-f = f-next;
-}
-
-if (!found) {
-f = apr_pcalloc(p, sizeof(ap_filter_rec_t));
-f-name = apr_pstrdup(p, base_info-name);
-f-next = cur;
-cur = f;
-}
-
-base_info = base_info-next;
-}
-
-return cur;
-}
-
static void *merge_core_dir_configs(apr_pool_t *a, void *basev, void *newv)
{
core_dir_config *base = (core_dir_config *)basev;
@@ -391,21 +337,6 @@
conf-input_filters = new-input_filters;
}
-if (conf-ct_output_filters new-ct_output_filters) {
-conf-ct_output_filters = apr_hash_merge(a,
- new-ct_output_filters,
- conf-ct_output_filters,
- merge_ct_filters,
- NULL);
-}
-else if (new-ct_output_filters) {
-conf-ct_output_filters = apr_hash_copy(a, new-ct_output_filters);
-}
-else if (conf-ct_output_filters) {
-/* That memcpy above isn't enough. */
-conf-ct_output_filters = apr_hash_copy(a, base-ct_output_filters);
-}
-
/*
* Now merge the setting of the FileETag directive.
*/
@@ -3037,88 +2968,6 @@
return 0;
}
-static const char *add_ct_output_filters(cmd_parms *cmd, void *conf_,
- const char *arg, const char *arg2)
-{
-core_dir_config *conf = conf_;
-ap_filter_rec_t *old, *new = NULL;
-const char *filter_name;
-
-if (!conf-ct_output_filters) {
-conf-ct_output_filters = apr_hash_make(cmd-pool);
-old = NULL;
-}
-else {
-old = (ap_filter_rec_t*) apr_hash_get(conf-ct_output_filters, arg2,
- APR_HASH_KEY_STRING);
-/* find last entry */
-if (old) {
-while (old-next) {
-old = old-next;
-}
-}
-}
-
-while (*arg
- (filter_name = ap_getword(cmd-pool, arg, ';'))
- strcmp(filter_name, )) {
-new = apr_pcalloc(cmd-pool, sizeof(ap_filter_rec_t));
-new-name = filter_name;
-
-/*
Re: Removing AddOutputFilterByType
* Nick Kew wrote: AddOutputFilterByType has always been problematic. I see there's another bug report this month arising from it: http://issues.apache.org/bugzilla/show_bug.cgi?id=33499 Since the purpose of this directive is now available from mod_filter, does anyone object if I simply yank AddOutputFilterByType from 2.1? Is mod_filter capable of something like this: AddOutputFilterByType INCLUDES httpd/unix-directory ? I'm personally using that heavily to get SSI into autoindex descriptions. nd -- Winnetous Erbe: http://pub.perlig.de/books.html#apache2
Re: Removing AddOutputFilterByType
Uhm, yes. Most definately object. Trying to map ever type that resolves back to, say, text/*, or text/html, would be an unnecessary pain. I'll look at those reports though, I still have some neurons of info about how/why it was implemented; perhaps I can help on those PR tickets. After my HTTP Request proxy test cluster is done so I'm happy with our solutions to the Watchfire report. Bill At 11:33 AM 6/19/2005, Nick Kew wrote: AddOutputFilterByType has always been problematic. I see there's another bug report this month arising from it: http://issues.apache.org/bugzilla/show_bug.cgi?id=33499 Since the purpose of this directive is now available from mod_filter, does anyone object if I simply yank AddOutputFilterByType from 2.1? I've hacked a quick patch just to remove it. If people are happy with it, I'll test it and commit, and add a note to the docs about replacing it. -- Nick Kew
Re: Removing AddOutputFilterByType
On Sunday 19 June 2005 17:47, William A. Rowe, Jr. wrote: Uhm, yes. Most definately object. Trying to map ever type that resolves back to, say, text/*, or text/html, would be an unnecessary pain. How is a regexp match FilterProvider textfilter my-filter content-type /^text/ or a substring match FilterProvider textfilter my-filter content-type $text/ an unnecessary pain? I'll look at those reports though, I still have some neurons of info about how/why it was implemented; perhaps I can help on those PR tickets. After my HTTP Request proxy test cluster is done so I'm happy with our solutions to the Watchfire report. Fairy nuff:-) But as a more general point, if there's something AddOutputFilterByType does that mod_filter doesn't do - or complicates doing -- Nick Kew
Re: Removing AddOutputFilterByType
On Sunday 19 June 2005 17:42, Andr Malo wrote: Is mod_filter capable of something like this: AddOutputFilterByType INCLUDES httpd/unix-directory ? I'm personally using that heavily to get SSI into autoindex descriptions. Yow! You mean httpd/unix-directory - which is most emphatically *not* a content type - is passing through ap_set_content_type? To answer your question, mod_filter can dispatch on r-handler, so if handler gets set to httpd/unix-directory then yes. If not, then it would need a workaround, such as dispatching on text/html and controlling the scope of that with a FilesMatch or something of that ilk. Or a patch to mod_filter. -- Nick Kew
Re: Removing AddOutputFilterByType
On Sunday 19 June 2005 19:57, Nick Kew wrote: But as a more general point, if there's something AddOutputFilterByType does that mod_filter doesn't do - or complicates doing Bah. I was going to say something about if [...] then mod_filter wants reviewing. Then I stopped, but didn't chop out the unfinished sentence. Sorry folks. -- Nick Kew
Re: 2.1.5 available for testing
At 03:07 PM 6/17/2005, William A. Rowe, Jr. wrote: -1 on Win32, caddr_t isn't sufficiently portable (fix committed). Correction, -1 on all platforms. jfclere just committed a significant patch to the T-E override of the C-L passed to us, as part of the Watchfire vulnerability fixes. It seems very irresponsible to release any flavor (alpha, beta, nadda) with a known vuln, when we've committed a fix already. Also, possibly across platforms is a fault in ssl_engine_init, where the host-protocol is still NULL, and we are trying to strcmp it to 'https'. I spent part of my weekend trying to grok what change has broken this, but strcmp to NULL is popping a segfault. Not worthy of rejecting 2.1.5 on it's own, this is still a minor irritation. FYI - mod_ssl was loaded without SSL being defined, so no ssl host actually exists. Bill
Re: Removing AddOutputFilterByType
--On June 19, 2005 5:33:14 PM +0100 Nick Kew [EMAIL PROTECTED] wrote: AddOutputFilterByType has always been problematic. I see there's another bug report this month arising from it: http://issues.apache.org/bugzilla/show_bug.cgi?id=33499 Since the purpose of this directive is now available from mod_filter, does anyone object if I simply yank AddOutputFilterByType from 2.1? Why can't AddOutputFilterByType call mod_filter under the hood? But, from the user's perspective, I think AddOutputFilterByType needs to stay and I'm not convinced that mod_filter has a good enough directive interface to make it intuitive. -- justin
