On Feb 8, 2008, at 5:45 PM, Plüm, Rüdiger, VF-Group wrote:
OTOH a comment from make_sub_request makes me think whether doing
this is the
correct thing:
/* If NULL - we are expecting to be internal_fast_redirect'ed
* to this subrequest - or this request will never be invoked.
* Ignore the original request filter stack entirely, and
* drill the input and output stacks back to the connection.
*/
I guess ap_internal_fast_redirect is always called before we call
ap_invoke_handler (which calls ap_run_insert_filter). So normally we
should not have setup
anything before the proto filters, except in the mod_cache situation
where ap_run_insert_filter
is run during the quick handler phase, by mod_cache's quick handler
and thus we have those filters
setup already.
Well not sure -- but what you see in terms of installed handlers is
this:
Thu Feb 07 14:12:32 2008] [debug] mod_cache.c(144): Adding CACHE_SAVE
filter for /foo/
[Thu Feb 07 14:12:32 2008] [debug] mod_cache.c(151): Adding
CACHE_REMOVE_URL filter for /foo/
mod_dir.c:111 Filters: r->output_filters:->cache_save ->byterange -
>content_length ->http_header ->http_outerror ->cache_remove_url ->core
... the check
mod_dir.c:111 Filters: r->output_filters:->byterange ->content_length -
>http_header ->http_outerror ->cache_remove_url ->core
.. the redirect
mod_dir.c:205 Filters: r->output_filters:->cache_save ->byterange -
>content_length ->http_header ->http_outerror ->cache_remove_url ->core
mod_dir.c:206 Filters: rr->output_filters:->byterange ->content_length
->http_header ->http_outerror ->cache_remove_url ->core
mod_dir: Calling Redir
Filters: r->output_filters:->byterange ->content_length ->http_header -
>http_outerror ->cache_remove_url ->core
Filters: rr->output_filters:->byterange ->content_length ->http_header
->http_outerror ->cache_remove_url ->core
Filters: r->proto_output_filters:->byterange ->content_length -
>http_header ->http_outerror ->cache_remove_url ->core
Filters: rr->proto_output_filters:->byterange ->content_length -
>http_header ->http_outerror ->cache_remove_url ->core
Filters: rr->proto_output_filters:->byterange ->content_length -
>http_header ->http_outerror ->cache_remove_url ->core
Filters: r->proto_output_filters:->byterange ->content_length -
>http_header ->http_outerror ->cache_remove_url ->core
mod_dir.c:211 Filters: r->output_filters:->byterange ->content_length -
>http_header ->http_outerror ->cache_remove_url ->core
mod_dir.c:212 Filters: rr->output_filters:->byterange ->content_length
->http_header ->http_outerror ->cache_remove_url ->core
[Thu Feb 07 14:12:32 2008] [debug] mod_cache.c(898):
cache_remove_url_filter
[Thu Feb 07 14:12:32 2008] [debug] mod_cache.c(918): cache:
ap_remove_output_filter cache_remove_url
So the 'redirect' is the actual closing request -- and the first iterm
-- cache_save is 'lost'.
Dw.
