* Bill Stoddard wrote:
> mod_expires (with my latest patch ) is still broken. The expires header
> will not be added when the resource is resolved via a DirectoryIndex
> (ie, a fast redirect) . mod_expires will not add the expires filter to
> what it believes to be a subrequest and a simple check of (r->main !=
> NULL) is not granular enough to tell of a request is a subrequest or a
> redirect/fast-redirect. I am not about to suggest that redirects
> should inherit the filter stack of the main request :-). An alternate
> solution is to add a flag to request_rec (or some other indicator) that
> a module can check to determine if a request is a true subrequest or a
> redirect (fast or normal). Perhaps set the flag in make_sub_req based
> on the 'next_filter' argument. Any other ideas?
Looking through the bugreports and the problems we have...
internal_fast_redirect saves some CPU cycles (I guess), but it's finally
(currently) an unclean thing.
IMHO we should drop and discourage the usage fast_redirects until the
concept (subreq/filters/data stream/redirects) has reached some more
maturity. Normal internal_redirects may be (a bit) slower, but they are
approved and work as expected, since they process a complete request.
I believe, the main problem of using them in DirectoryIndex is the late
stage (fixup hook) they are invoked. Some important things can not be done
with that concept, since they are not executed in subrequests but already
done in the main. (and some things may be done twice) (e.g.: expires,
cookies, RewriteRules (!) and probably more).
Perhaps the type_checker (which handles Multiviews) is actually the last
stage where fast_redirects make any sense.
Some more thoughts would be really helpful.
nd
--
Das, was ich nicht kenne, spielt st�ckzahlm��ig *keine* Rolle.
-- Helmut Schellong in dclc
