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 Mon, 23 Jan 2012 19:26:45 GMT

Matthew Byng-Maddick <> changed:

           What    |Removed                     |Added
          Component|Core                        |mod_include

--- Comment #6 from Matthew Byng-Maddick <> 2012-01-23
19:26:45 UTC ---
So, having dug a lot deeper, and with a lot more ap_log_rerror(APLOG_MARK,
APLOG_DEBUG...) lines, I've finally found why this doesn't work, it's not
actually to do with keeping the filters or not, though obviously keeping the
existing filter, and the existing context in the internal-redirect case does
help (but is wrong).

It's actually what happens in mod_include, basically, in handle_include()
(which handles the <!--#include tag, we make the subrequest (as a file or uri),
which creates a completely empty r->request_config, fine. Before we call
ap_run_sub_req() on the new subrequest request_rec (which is actually called
"rr" in that function) we do:
        /* See the Kludge in includes_filter for why.
         * Basically, it puts a bread crumb in here, then looks
         * for the crumb later to see if its been here.
        if (rr) {
            ap_set_module_config(rr->request_config, &include_module, r);

In the actual filtering call (includes_filter()), we find:
    if ((parent = ap_get_module_config(r->request_config, &include_module))) {
        /* Kludge --- for nested includes, we want to keep the subprocess
         * environment of the base document (for compatibility); that means
         * torquing our own last_modified date as well so that the
         * LAST_MODIFIED variable gets reset to the proper value if the
         * nested document resets <!--#config timefmt -->.
        r->subprocess_env = r->main->subprocess_env;
        apr_pool_join(r->main->pool, r->pool);
        r->finfo.mtime = r->main->finfo.mtime;
    else {
        /* we're not a nested include, so we create an initial
         * environment */

This is obviously absolutely horrid, and explains why this doesn't work. I'm
guessing that the actual handling should be something like:
    while(initr->prev) {
        initr = initr->prev;
    if ((parent = ap_get_module_config(initr->request_config,
&include_module))) {
        r->subprocess_env = parent->subprocess_env;
using parent (as the token stuck in) rather than r->main.

With that in place, it can still be perfectly possible to set filters based on
existing stuff, without necessarily needing Graham's patches to mod_mime which
I definitely have concerns about.

This seems like the right solution here, though because you don't have a proper
r->request_config set up, I'm wondering if it can be done with a switch on
mod_include, so as not to change existing functionality generically.



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