You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dirk-Willem van Gulik <di...@webweaving.org> on 2008/02/08 16:32:06 UTC
ap_sub_req_lookup_* loosing filter context
In a number of places we are usingL
... = ap_sub_req_lookup_uri(..., r, NULL);
... = ap_sub_req_lookup_file(..., r, NULL);
... = ap_sub_req_lookup_dirent...., NULL);
... = ap_sub_req_lookup_uri( ... ,NULL);
Where null is the output filter to preserve, if any (at NULL
proto_output_filter is used).
We do this to see what a sub request would look like; and then later
on we clean it up; perhaps after capturing some result, modified path,
filling out some SSI etc (e.g. mod_include, mod_isapi, mod_auto_index,
mod_cgid, mod_cern, mod_mime_magic or mod_rewrite). And then we
discart the sub request and continue with the real request.
However we also occasionally do NOT do this - but make the thus
created sub request as the main request i.e. some redirect where we
do not discard the sub_req -- but continue to operate on it (e.g. the
core of mod_dir, mod_negotiation) - and pass it to a
internal(fast)redirect.
Am I right to understand that this is not correct ?
As far as I can see (see patch below) - there is no harmful side
effect from fixing this - while it does seem to fix mod_cache when
dealing with content remappings done by mod_dir and mod_negotation.
Thoughts ?
Dw
Index: modules/mappers/mod_negotiation.c
===================================================================
--- modules/mappers/mod_negotiation.c (revision 618646)
+++ modules/mappers/mod_negotiation.c (working copy)
@@ -1165,8 +1165,10 @@
/* Double check, we still don't multi-resolve non-ordinary
files
*/
- if (sub_req->finfo.filetype != APR_REG)
+ if (sub_req->finfo.filetype != APR_REG) {
+ /* XXX sub req not destroyed */
continue;
+ }
/* If it has a handler, we'll pretend it's a CGI script,
* since that's a good indication of the sort of thing it
@@ -3122,7 +3124,7 @@
* a sub_req structure yet. Get one now.
*/
- sub_req = ap_sub_req_lookup_file(best->file_name, r, NULL);
+ sub_req = ap_sub_req_lookup_file(best->file_name, r, r-
>output_filter);
if (sub_req->status != HTTP_OK) {
res = sub_req->status;
ap_destroy_sub_req(sub_req);
Index: modules/mappers/mod_dir.c
===================================================================
--- modules/mappers/mod_dir.c (revision 618646)
+++ modules/mappers/mod_dir.c (working copy)
@@ -176,7 +185,8 @@
name_ptr = apr_pstrcat(r->pool, name_ptr, "?", r->args,
NULL);
}
- rr = ap_sub_req_lookup_uri(name_ptr, r, NULL);
+ rr = ap_sub_req_lookup_uri(name_ptr, r, r->output_filters);
/* The sub request lookup is very liberal, and the core
map_to_storage
* handler will almost always result in HTTP_OK as /foo/
index.html
Re: ap_sub_req_lookup_* loosing filter context
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Dirk-Willem van Gulik wrote:
> In a number of places we are usingL
>
> ... = ap_sub_req_lookup_uri(..., r, NULL);
> ... = ap_sub_req_lookup_file(..., r, NULL);
> ... = ap_sub_req_lookup_dirent...., NULL);
> ... = ap_sub_req_lookup_uri( ... ,NULL);
>
> Where null is the output filter to preserve, if any (at NULL
> proto_output_filter is used).
>
> We do this to see what a sub request would look like; and then later on
> we clean it up; perhaps after capturing some result, modified path,
> filling out some SSI etc (e.g. mod_include, mod_isapi, mod_auto_index,
> mod_cgid, mod_cern, mod_mime_magic or mod_rewrite). And then we discart
> the sub request and continue with the real request.
>
> However we also occasionally do NOT do this - but make the thus created
> sub request as the main request i.e. some redirect where we do not
> discard the sub_req -- but continue to operate on it (e.g. the core of
> mod_dir, mod_negotiation) - and pass it to a internal(fast)redirect.
>
> Am I right to understand that this is not correct ?
I agree it looks like a flaw... apply your proposed fix to trunk, and let's
slowly move on backporting to 2.2 to ensure no evil side-effects?
Bill
Re: ap_sub_req_lookup_* loosing filter context
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Feb 11, 2008, at 2:42 PM, Jim Jagielski wrote:
> We should likely "correct" the comment in make_sub_request
> at the same time ;)
I am going to punt here - as I am not sure I fully grasp all the
implications.
Dw
Re: ap_sub_req_lookup_* loosing filter context
Posted by Jim Jagielski <ji...@jaguNET.com>.
We should likely "correct" the comment in make_sub_request
at the same time ;)
On Feb 8, 2008, at 6:33 PM, Dirk-Willem van Gulik wrote:
>
> On Feb 9, 2008, at 12:18 AM, Dirk-Willem van Gulik wrote:
>
>>
>> On Feb 9, 2008, at 12:07 AM, Ruediger Pluem wrote:
>>
>>>>> I guess this happens in at least one more location at
>>>>> mod_negotiation
>>>>> that would also need fixing (in setup_choice_response).
>>>>
>>>> Below are all the only two places I could find. Let me know which
>>>> ones I
>>>> missed !
>>>
>>> IMHO this one is missing:
>>>
>>> Index: mod_negotiation.c
>>> ===================================================================
>>> --- mod_negotiation.c (Revision 619126)
>>> +++ mod_negotiation.c (Arbeitskopie)
>>> @@ -2712,7 +2712,7 @@
>>> if (!variant->sub_req) {
>>> int status;
>>>
>>> - sub_req = ap_sub_req_lookup_file(variant->file_name, r,
>>> NULL);
>>> + sub_req = ap_sub_req_lookup_file(variant->file_name, r, r-
>>> >output_filters));
>>> status = sub_req->status;
>>>
>>> if (status != HTTP_OK &&
>>>
>>
>> Ah - excelent -- and i think that fixed a bug I had as well.
>
>
> It did. I'll probably commit, with a large "Warning - this may
> subtly break things", below when I am a bit more awake :) Bed time
> here.
>
> Dw.
>
> 4x4:httpd-trunk-filters dirkx$ svn diff CHANGES modules/mappers/
> Index: CHANGES
> ===================================================================
> --- CHANGES (revision 620036)
> +++ CHANGES (working copy)
> @@ -2,6 +2,12 @@
> Changes with Apache 2.3.0
> [ When backported to 2.2.x, remove entry from this file ]
>
> + *) mod_dir, mod_negotiation: pass the output filter information
> + to newly created sub requests; as these are later on used
> + as true requests with an internal redirect. This allows for
> + mod_cache et.al. to trap the results of the redirect.
> + [Dirk-Willem van Gulik, Ruediger Pluem]
> +
> *) ab: Use a 64 bit unsigned int instead of a signed long to count
> the
> bytes transferred to avoid integer overflows. PR 44346
> [Ruediger Pluem]
>
> Index: modules/mappers/mod_dir.c
> ===================================================================
> --- modules/mappers/mod_dir.c (revision 620036)
> +++ modules/mappers/mod_dir.c (working copy)
> @@ -176,7 +176,7 @@
> name_ptr = apr_pstrcat(r->pool, name_ptr, "?", r->args,
> NULL);
> }
>
> - rr = ap_sub_req_lookup_uri(name_ptr, r, NULL);
> + rr = ap_sub_req_lookup_uri(name_ptr, r, r->output_filters);
>
> /* The sub request lookup is very liberal, and the core
> map_to_storage
> * handler will almost always result in HTTP_OK as /foo/
> index.html
> Index: modules/mappers/mod_negotiation.c
> ===================================================================
> --- modules/mappers/mod_negotiation.c (revision 620036)
> +++ modules/mappers/mod_negotiation.c (working copy)
> @@ -1165,8 +1165,10 @@
>
> /* Double check, we still don't multi-resolve non-ordinary
> files
> */
> - if (sub_req->finfo.filetype != APR_REG)
> + if (sub_req->finfo.filetype != APR_REG) {
> + /* XXX sub req not destroyed -- may be a bug/unintentional ? */
> continue;
> + }
>
> /* If it has a handler, we'll pretend it's a CGI script,
> * since that's a good indication of the sort of thing it
> @@ -2712,7 +2714,7 @@
> if (!variant->sub_req) {
> int status;
>
> - sub_req = ap_sub_req_lookup_file(variant->file_name, r,
> NULL);
> + sub_req = ap_sub_req_lookup_file(variant->file_name, r, r-
> >output_filters);
> status = sub_req->status;
>
> if (status != HTTP_OK &&
> @@ -3122,7 +3124,7 @@
> * a sub_req structure yet. Get one now.
> */
>
> - sub_req = ap_sub_req_lookup_file(best->file_name, r, NULL);
> + sub_req = ap_sub_req_lookup_file(best->file_name, r, r-
> >output_filters);
> if (sub_req->status != HTTP_OK) {
> res = sub_req->status;
> ap_destroy_sub_req(sub_req);
>
Re: ap_sub_req_lookup_* loosing filter context
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Feb 9, 2008, at 12:18 AM, Dirk-Willem van Gulik wrote:
>
> On Feb 9, 2008, at 12:07 AM, Ruediger Pluem wrote:
>
>>>> I guess this happens in at least one more location at
>>>> mod_negotiation
>>>> that would also need fixing (in setup_choice_response).
>>>
>>> Below are all the only two places I could find. Let me know which
>>> ones I
>>> missed !
>>
>> IMHO this one is missing:
>>
>> Index: mod_negotiation.c
>> ===================================================================
>> --- mod_negotiation.c (Revision 619126)
>> +++ mod_negotiation.c (Arbeitskopie)
>> @@ -2712,7 +2712,7 @@
>> if (!variant->sub_req) {
>> int status;
>>
>> - sub_req = ap_sub_req_lookup_file(variant->file_name, r,
>> NULL);
>> + sub_req = ap_sub_req_lookup_file(variant->file_name, r, r-
>> >output_filters));
>> status = sub_req->status;
>>
>> if (status != HTTP_OK &&
>>
>
> Ah - excelent -- and i think that fixed a bug I had as well.
It did. I'll probably commit, with a large "Warning - this may subtly
break things", below when I am a bit more awake :) Bed time here.
Dw.
4x4:httpd-trunk-filters dirkx$ svn diff CHANGES modules/mappers/
Index: CHANGES
===================================================================
--- CHANGES (revision 620036)
+++ CHANGES (working copy)
@@ -2,6 +2,12 @@
Changes with Apache 2.3.0
[ When backported to 2.2.x, remove entry from this file ]
+ *) mod_dir, mod_negotiation: pass the output filter information
+ to newly created sub requests; as these are later on used
+ as true requests with an internal redirect. This allows for
+ mod_cache et.al. to trap the results of the redirect.
+ [Dirk-Willem van Gulik, Ruediger Pluem]
+
*) ab: Use a 64 bit unsigned int instead of a signed long to count
the
bytes transferred to avoid integer overflows. PR 44346
[Ruediger Pluem]
Index: modules/mappers/mod_dir.c
===================================================================
--- modules/mappers/mod_dir.c (revision 620036)
+++ modules/mappers/mod_dir.c (working copy)
@@ -176,7 +176,7 @@
name_ptr = apr_pstrcat(r->pool, name_ptr, "?", r->args,
NULL);
}
- rr = ap_sub_req_lookup_uri(name_ptr, r, NULL);
+ rr = ap_sub_req_lookup_uri(name_ptr, r, r->output_filters);
/* The sub request lookup is very liberal, and the core
map_to_storage
* handler will almost always result in HTTP_OK as /foo/
index.html
Index: modules/mappers/mod_negotiation.c
===================================================================
--- modules/mappers/mod_negotiation.c (revision 620036)
+++ modules/mappers/mod_negotiation.c (working copy)
@@ -1165,8 +1165,10 @@
/* Double check, we still don't multi-resolve non-ordinary
files
*/
- if (sub_req->finfo.filetype != APR_REG)
+ if (sub_req->finfo.filetype != APR_REG) {
+ /* XXX sub req not destroyed -- may be a bug/unintentional ? */
continue;
+ }
/* If it has a handler, we'll pretend it's a CGI script,
* since that's a good indication of the sort of thing it
@@ -2712,7 +2714,7 @@
if (!variant->sub_req) {
int status;
- sub_req = ap_sub_req_lookup_file(variant->file_name, r, NULL);
+ sub_req = ap_sub_req_lookup_file(variant->file_name, r, r-
>output_filters);
status = sub_req->status;
if (status != HTTP_OK &&
@@ -3122,7 +3124,7 @@
* a sub_req structure yet. Get one now.
*/
- sub_req = ap_sub_req_lookup_file(best->file_name, r, NULL);
+ sub_req = ap_sub_req_lookup_file(best->file_name, r, r-
>output_filters);
if (sub_req->status != HTTP_OK) {
res = sub_req->status;
ap_destroy_sub_req(sub_req);
Re: ap_sub_req_lookup_* loosing filter context
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Feb 9, 2008, at 12:07 AM, Ruediger Pluem wrote:
>>> I guess this happens in at least one more location at
>>> mod_negotiation
>>> that would also need fixing (in setup_choice_response).
>>
>> Below are all the only two places I could find. Let me know which
>> ones I
>> missed !
>
> IMHO this one is missing:
>
> Index: mod_negotiation.c
> ===================================================================
> --- mod_negotiation.c (Revision 619126)
> +++ mod_negotiation.c (Arbeitskopie)
> @@ -2712,7 +2712,7 @@
> if (!variant->sub_req) {
> int status;
>
> - sub_req = ap_sub_req_lookup_file(variant->file_name, r,
> NULL);
> + sub_req = ap_sub_req_lookup_file(variant->file_name, r, r-
> >output_filters));
> status = sub_req->status;
>
> if (status != HTTP_OK &&
>
Ah - excelent -- and i think that fixed a bug I had as well.
Dw.
Re: ap_sub_req_lookup_* loosing filter context
Posted by Ruediger Pluem <rp...@apache.org>.
On 02/08/2008 11:34 PM, Dirk-Willem van Gulik wrote:
>
> On Feb 8, 2008, at 5:45 PM, Plüm, Rüdiger, VF-Group wrote:
>
>>> However we also occasionally do NOT do this - but make the thus
>>> created sub request as the main request i.e. some redirect where we
>>> do not discard the sub_req -- but continue to operate on it
>>> (e.g. the
>>> core of mod_dir, mod_negotiation) - and pass it to a
>>> internal(fast)redirect.
>>>
> ...
>> I guess this happens in at least one more location at mod_negotiation
>> that would also need fixing (in setup_choice_response).
>
> Below are all the only two places I could find. Let me know which ones I
> missed !
IMHO this one is missing:
Index: mod_negotiation.c
===================================================================
--- mod_negotiation.c (Revision 619126)
+++ mod_negotiation.c (Arbeitskopie)
@@ -2712,7 +2712,7 @@
if (!variant->sub_req) {
int status;
- sub_req = ap_sub_req_lookup_file(variant->file_name, r, NULL);
+ sub_req = ap_sub_req_lookup_file(variant->file_name, r, r->output_filters));
status = sub_req->status;
if (status != HTTP_OK &&
Regards
Rüdiger
Re: ap_sub_req_lookup_* loosing filter context
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Feb 8, 2008, at 5:45 PM, Plüm, Rüdiger, VF-Group wrote:
>> However we also occasionally do NOT do this - but make the thus
>> created sub request as the main request i.e. some redirect where we
>> do not discard the sub_req -- but continue to operate on it
>> (e.g. the
>> core of mod_dir, mod_negotiation) - and pass it to a
>> internal(fast)redirect.
>>
...
> I guess this happens in at least one more location at mod_negotiation
> that would also need fixing (in setup_choice_response).
Below are all the only two places I could find. Let me know which ones
I missed !
Dw
4x4:httpd-trunk dirkx$ svn diff modules/mappers/
Index: modules/mappers/mod_dir.c
===================================================================
--- modules/mappers/mod_dir.c (revision 618646)
+++ modules/mappers/mod_dir.c (working copy)
@@ -176,7 +185,8 @@
name_ptr = apr_pstrcat(r->pool, name_ptr, "?", r->args,
NULL);
}
- rr = ap_sub_req_lookup_uri(name_ptr, r, NULL);
+/* XXXX */
+ rr = ap_sub_req_lookup_uri(name_ptr, r, r->output_filters);
/* The sub request lookup is very liberal, and the core
map_to_storage
* handler will almost always result in HTTP_OK as /foo/
index.html
Index: modules/mappers/mod_negotiation.c
===================================================================
--- modules/mappers/mod_negotiation.c (revision 618646)
+++ modules/mappers/mod_negotiation.c (working copy)
@@ -1165,8 +1165,10 @@
/* Double check, we still don't multi-resolve non-ordinary
files
*/
- if (sub_req->finfo.filetype != APR_REG)
+ if (sub_req->finfo.filetype != APR_REG) {
+ /* XXX sub req not destroyed */
continue;
+ }
/* If it has a handler, we'll pretend it's a CGI script,
* since that's a good indication of the sort of thing it
@@ -3122,7 +3124,7 @@
* a sub_req structure yet. Get one now.
*/
- sub_req = ap_sub_req_lookup_file(best->file_name, r, NULL);
+ sub_req = ap_sub_req_lookup_file(best->file_name, r, r-
>output_filters);
if (sub_req->status != HTTP_OK) {
res = sub_req->status;
ap_destroy_sub_req(sub_req);
Re: ap_sub_req_lookup_* loosing filter context
Posted by Ruediger Pluem <rp...@apache.org>.
On 02/08/2008 11:34 PM, Dirk-Willem van Gulik wrote:
> 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'.
Yes, I agree with you, but I did not express this clearly enough in my previous
mail. The comment in make_sub_request made me think about this deeper. But in
the next paragraph I thought out loud and wrote down why the comment in make_sub_request
seems to make the *wrong* assumption (that ap_run_insert_filter has not been run yet).
I assume that this comment is older than mod_cache and the quick handler stuff
so it was correct back then. So I think it is correct to move forward with
your fixes in trunk and let us see if this breaks something.
Regards
Rüdiger
Re: ap_sub_req_lookup_* loosing filter context
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
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.
Re: ap_sub_req_lookup_* loosing filter context
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Dirk-Willem van Gulik
> Gesendet: Freitag, 8. Februar 2008 16:32
> An: dev@httpd.apache.org
> Betreff: ap_sub_req_lookup_* loosing filter context
>
> In a number of places we are usingL
>
> ... = ap_sub_req_lookup_uri(..., r, NULL);
> ... = ap_sub_req_lookup_file(..., r, NULL);
> ... = ap_sub_req_lookup_dirent...., NULL);
> ... = ap_sub_req_lookup_uri( ... ,NULL);
>
> Where null is the output filter to preserve, if any (at NULL
> proto_output_filter is used).
>
> We do this to see what a sub request would look like; and then later
> on we clean it up; perhaps after capturing some result,
> modified path,
> filling out some SSI etc (e.g. mod_include, mod_isapi,
> mod_auto_index,
> mod_cgid, mod_cern, mod_mime_magic or mod_rewrite). And then we
> discart the sub request and continue with the real request.
>
> However we also occasionally do NOT do this - but make the thus
> created sub request as the main request i.e. some redirect where we
> do not discard the sub_req -- but continue to operate on it
> (e.g. the
> core of mod_dir, mod_negotiation) - and pass it to a
> internal(fast)redirect.
>
> Am I right to understand that this is not correct ?
>
> As far as I can see (see patch below) - there is no harmful side
> effect from fixing this - while it does seem to fix mod_cache when
> dealing with content remappings done by mod_dir and mod_negotation.
>
> Thoughts ?
>
> Dw
>
> Index: modules/mappers/mod_negotiation.c
> ===================================================================
> --- modules/mappers/mod_negotiation.c (revision 618646)
> +++ modules/mappers/mod_negotiation.c (working copy)
> @@ -1165,8 +1165,10 @@
>
> /* Double check, we still don't multi-resolve non-ordinary
> files
> */
> - if (sub_req->finfo.filetype != APR_REG)
> + if (sub_req->finfo.filetype != APR_REG) {
> + /* XXX sub req not destroyed */
> continue;
> + }
>
> /* If it has a handler, we'll pretend it's a CGI script,
> * since that's a good indication of the sort of thing it
> @@ -3122,7 +3124,7 @@
> * a sub_req structure yet. Get one now.
> */
>
> - sub_req = ap_sub_req_lookup_file(best->file_name, r, NULL);
> + sub_req = ap_sub_req_lookup_file(best->file_name, r, r-
> >output_filter);
> if (sub_req->status != HTTP_OK) {
> res = sub_req->status;
> ap_destroy_sub_req(sub_req);
I guess this happens in at least one more location at mod_negotiation
that would also need fixing (in setup_choice_response).
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.
Regards
Rüdiger