Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of dirkx@webweaving.org
 designates 209.132.96.45 as permitted sender)
Message-Id: <08E3D573-FFFF-4B56-B26D-321349FBC6CC@webweaving.org>
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
To: dev@httpd.apache.org
In-Reply-To: 
 <99EA83DCDE961346AFA9B5EC33FEC08B46461D@VF-MBX11.internal.vodafone.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: ap_sub_req_lookup_* loosing filter context
Date: Fri, 8 Feb 2008 23:34:42 +0100
References: <335D1A4B-25E2-4FF1-8CDF-5010A7FBD293@webweaving.org>
 <99EA83DCDE961346AFA9B5EC33FEC08B46461D@VF-MBX11.internal.vodafone.com>

On Feb 8, 2008, at 5:45 PM, Pl=FCm, R=FCdiger, VF-Group wrote:

> OTOH a comment from make_sub_request makes me think whether doing =20
> 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 =20=

> should not have setup
> anything before the proto filters, except in the mod_cache situation =20=

> where ap_run_insert_filter
> is run during the quick handler phase, by mod_cache's quick handler =20=

> and thus we have those filters
> setup already.


Well not sure -- but what you see in terms of installed handlers is =20
this:

Thu Feb 07 14:12:32 2008] [debug] mod_cache.c(144): Adding CACHE_SAVE =20=

filter for /foo/
[Thu Feb 07 14:12:32 2008] [debug] mod_cache.c(151): Adding =20
CACHE_REMOVE_URL filter for /foo/
mod_dir.c:111 Filters: r->output_filters:->cache_save ->byterange -=20
 >content_length ->http_header ->http_outerror ->cache_remove_url ->core
... the check
mod_dir.c:111 Filters: r->output_filters:->byterange ->content_length -=20=

 >http_header ->http_outerror ->cache_remove_url ->core
.. the redirect
mod_dir.c:205 Filters: r->output_filters:->cache_save ->byterange -=20
 >content_length ->http_header ->http_outerror ->cache_remove_url ->core
mod_dir.c:206 Filters: rr->output_filters:->byterange ->content_length =20=

->http_header ->http_outerror ->cache_remove_url ->core
mod_dir: Calling Redir
Filters: r->output_filters:->byterange ->content_length ->http_header -=20=

 >http_outerror ->cache_remove_url ->core
Filters: rr->output_filters:->byterange ->content_length ->http_header =20=

->http_outerror ->cache_remove_url ->core
Filters: r->proto_output_filters:->byterange ->content_length -=20
 >http_header ->http_outerror ->cache_remove_url ->core
Filters: rr->proto_output_filters:->byterange ->content_length -=20
 >http_header ->http_outerror ->cache_remove_url ->core
Filters: rr->proto_output_filters:->byterange ->content_length -=20
 >http_header ->http_outerror ->cache_remove_url ->core
Filters: r->proto_output_filters:->byterange ->content_length -=20
 >http_header ->http_outerror ->cache_remove_url ->core

mod_dir.c:211 Filters: r->output_filters:->byterange ->content_length -=20=

 >http_header ->http_outerror ->cache_remove_url ->core
mod_dir.c:212 Filters: rr->output_filters:->byterange ->content_length =20=

->http_header ->http_outerror ->cache_remove_url ->core
[Thu Feb 07 14:12:32 2008] [debug] mod_cache.c(898): =20
cache_remove_url_filter
[Thu Feb 07 14:12:32 2008] [debug] mod_cache.c(918): cache: =20
ap_remove_output_filter cache_remove_url

So the 'redirect' is the actual closing request -- and the first iterm =20=

-- cache_save is 'lost'.

Dw.=