need help; main filters are bypassed on internal redirects in subrequests

[André Malo <nd...@perlig.de>]

Bah, what a complicated situation ;-)
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17629> gives a good 
example (reproducable with a standard installation + SSI + DEFLATE 
configured).

The attached patch solves the problem for me. But somehow I have the 
feeling, that it's not the end solution (but would be cool, if it is :). 
I'm not sure about all of the implications. What happens, for example, if 
the redirects adds some filters itself?

Some review or hints would be appreciated.

nd
-- 
die (eval q-qq[Just Another Perl Hacker
]
;-)
# André Malo, <http://www.perlig.de/> #

Re: need help; main filters are bypassed on internal redirects in subrequests

[André Malo <nd...@perlig.de>]

* Stas Bekman wrote:

>> The attached patch solves the problem for me. But somehow I have the
>> feeling, that it's not the end solution (but would be cool, if it is :).
>> I'm not sure about all of the implications. What happens, for example, if
>> the redirects adds some filters itself?
> 
> Or some filter removes itself. Also what happens to the filter context? You
> probably need to "deep-copy" the chain.

After some sleeping and further thinking about it...

I think, the solution (simply pointing to the upper request's filter chain) 
is correct -- for now.
If a filter removes itself from the chain after the first bucket, it's 
intended or broken. Actually we have that problem for entire subrequest, 
because we never deep-copy the chain.

For the (far?) future, we should think about a cleaner handling of the 
filter chains. If I understand all of it, the correct way would be:

- the main request has it's normal complete filter chain (resource -> proto 
  -> conn)
- subrequests semantically do not have a connection, so they cannot have 
valid connection filters. the subreq-filter (the pendant of the core 
network output filter) would move all buckets from the last proto filter 
back to the upper request's filter chain.

It's similar to the current state but nevertheless a big effort, IMHO.
Needs probably some further research.

However, if there are no objections, I'm going to apply the proposed patch 
for internal_redirect (and fast_redirect) ;-)

Opinions are greatly welcome.

nd
-- 
s;.*;aaaaaoaaaoaaaaooooaaoaaaomaaaa:a:alataa:aaoat:a:a:a
maoaa:a:laoata:a:oia:a:o:a:m:a:o:alaoooat:aaool:aaoaa
matooololaaatoto:aaa:o:a:o:m;;s:\s:\::g;y;mailto:;
\40\51/\134\137|ndparker <nd...@perlig.de>;;print;

Re: need help; main filters are bypassed on internal redirects in subrequests

[Stas Bekman <st...@stason.org>]

André Malo wrote:
> Bah, what a complicated situation ;-)
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17629> gives a good 
> example (reproducable with a standard installation + SSI + DEFLATE 
> configured).
> 
> The attached patch solves the problem for me. But somehow I have the 
> feeling, that it's not the end solution (but would be cool, if it is :). 
> I'm not sure about all of the implications. What happens, for example, if 
> the redirects adds some filters itself?

Or some filter removes itself. Also what happens to the filter context? You 
probably need to "deep-copy" the chain.

> Index: modules/http/http_request.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/modules/http/http_request.c,v
> retrieving revision 1.154
> diff -u -r1.154 http_request.c
> --- modules/http/http_request.c	24 Feb 2003 00:57:40 -0000	1.154
> +++ modules/http/http_request.c	8 Mar 2003 01:38:48 -0000
> @@ -398,6 +398,9 @@
>      new->input_filters   = new->proto_input_filters;
>  
>      if (new->main) {
> +        new->output_filters = r->output_filters;
> +        new->input_filters = r->input_filters;
> +
>          /* Add back the subrequest filter, which we lost when
>           * we set output_filters to include only the protocol
>           * output filters from the original request.


-- 


__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com