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