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, 16 Jan 2012 12:26:31 GMT

--- Comment #2 from Matthew Byng-Maddick <> 2012-01-16
12:26:31 UTC ---
I've spent a lot more time thinking about this, and Graham (minfrin) and I have
had some discussions about this in private email...

There's a definite issue in that a sub-request delegation, while it, obviously,
creates a new request_rec doesn't actually scan through the filters and update
f->r for each filter in the chain, if an internal_redirect happens, it creates
the new request_rec, and does scan the filters and reset f->r to the redirected

While it's obvious that if you're not in a sub-request context this is the
right behaviour for the internal_redirect, the inconsistency between a plain
sub-request and a sub-request that you end up internal_redirecting seems wrong.
My patch is definitely wrong in (a) keeping the filter chain - in fact, my
initial claims were wrong - though I don't like them, because of the order of
processing, and (b) adjusting the notes.

Now, I suspect that we can't just change this unilaterally - because it is such
a major change in behaviour - so the question is what should happen? Do we keep
the separate "don't update the f->r s" function, and allow mod_rewrite to call
that with a RewriteOption - this seems really ugly, as there are presumably
other situations where the internal_redirect could happen in a sub-request and
those won't necessarily call it? Do we have some flag set on any request_rec,
but then you need to traverse the request_rec calling chain to find out what
you're supposed to be doing? Other suggestions?

I may patch our local copy of mod_rewrite to solve my immediate problems with
something like the above, and apply minfrin's patch within this ticket to drop
the r->proxyreq check off mod_mime.c, but it would be nice if there were a
sensible way of solving this in a consistent way...



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