httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 52342] ap_internal_redirect dropping filters means inconsistent behaviour for includes
Date Sat, 17 Dec 2011 13:36:10 GMT

--- Comment #1 from Graham Leggett <> 2011-12-17 13:36:10 UTC ---
I'm smelling a bug - if you're using AddOuputFilter, that's all processed
within mod_mime.c in the type_checker hook, which in turn runs before fixups,
and this in turn is triggered from ap_process_request_internal(), which is in
turn triggered from ap_internal_redirect(), which is called by mod_rewrite in
your case, so the output filters should be re-added when the request comes
round again, the trick is finding out why this isn't happening.

Further digging finds two possible causes, and we might be suffering both:

- Something inside mod_mime.c:find_ct is aborting early and isn't reaching the
point where output_filters are added. Would it be possible to put a breakpoint
here and see if we ever reach this code? We'll reach it at least once for the
initial request, key though is that we should reach this again for the internal
direct, if we don't, we'd need to see why it's bailing out early. Most
specifically, do we reach this code:

           if (exinfo->output_filters && r->proxyreq == PROXYREQ_NONE) {
               const char *filter, *filters = exinfo->output_filters;
               while (*filters
                   && (filter = ap_getword(r->pool, &filters, ';'))) {
                   ap_add_output_filter(filter, NULL, r, r->connection);
               if (conf->multimatch & MULTIMATCH_FILTERS) {
                   found = 1;

I suspect we might be reaching this code, only to find we've detected it as a
proxy request, and therefore aren't adding filters (In other words "r->proxyreq
== PROXYREQ_NONE" is false).

I can kinda-sorta see why we might want to not apply extensions to proxy
requests, but then at the same time I also see cases like this one where we
would want to - the URL ends with .sssi, whether it comes from a proxy or not,
who cares, we want the INCLUDES filter.

I suspect the fix might be to add a config directive that allows the end user
to ignore the "r->proxyreq == PROXYREQ_NONE" bit, or to just take that away
entirely (in 2.4).

In fact, this might be the cause of the inconsistency between using a ProxyPass
and the mod_rewrite [P] flag - in the ProxyPass case, r->proxyreq ==
PROXYREQ_NONE is false and this code is bypassed. In the [P] flag case,
r->proxyreq == PROXYREQ_NONE is true because the [P] flag hasn't been evaluated
yet (I *think* that happens 1 phase later, in fixups), so we get our filters in
this case.

Try this patch in other words, does this make it work?

Index: modules/http/mod_mime.c
--- modules/http/mod_mime.c    (revision 1214429)
+++ modules/http/mod_mime.c    (working copy)
@@ -895,7 +895,7 @@
             * setting redundant filters.    2, we insert these in the types
             * config hook, which may be too early (dunno.)
-            if (exinfo->input_filters && r->proxyreq == PROXYREQ_NONE) {
+            if (exinfo->input_filters) {
                const char *filter, *filters = exinfo->input_filters;
                while (*filters
                    && (filter = ap_getword(r->pool, &filters, ';'))) {
@@ -905,7 +905,7 @@
                    found = 1;
-            if (exinfo->output_filters && r->proxyreq == PROXYREQ_NONE) {
+            if (exinfo->output_filters) {
                const char *filter, *filters = exinfo->output_filters;
                while (*filters
                    && (filter = ap_getword(r->pool, &filters, ';'))) {

- AddOutputFilter doesn't actually mean "add" (and this is broken). Tracing the
code, when we merge configs from one location/directory to another, we end up
replacing the previous filter definition for that extension, instead of adding
it. Or to put this another way, if you have this:

AddOutputFilter FOO html
<Location /baz>
 AddOutputFilter BAR html

The BAR filter ends up replacing the FOO filter completely for the html type,
which is broken - add should mean just that, add, not replace.

To test this, put a breakpoint inside mod_mime:overlay_extension_mappings, and
see if you reach this code:

   if (overlay_info->output_filters) {
       new_info->output_filters = overlay_info->output_filters;

In theory, you should reach this code twice. If this bug is present, you'll
reach a point where new_info->output_filters evaluates to "INCLUDES" (or
something containing INCLUDES), and overlay_info->output_filters evaluates to
something else (like "BUFFER", or "DEFLATE", or...).

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message