Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4C0E5CE6.8020905@conversis.de>
Date: Tue, 08 Jun 2010 17:08:22 +0200
From: "Dennis J." <dennisml@conversis.de>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc11 Thunderbird/3.0.4
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: [PATCH] PR 17629 and all that
References: <20100608123737.GA27559@redhat.com>
In-Reply-To: <20100608123737.GA27559@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 06/08/2010 02:37 PM, Joe Orton wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=17629
>
> Here's an attempt at fixing the dreaded PR 17629.  This is a bug in the
> handling of the output filter chain at the point where an internal
> redirect is applied to a subrequest.  Complications:
>
> a) a subrequest's filter chain may start at an arbitrary point in
> r->main's filter chain
>
>   -- for an SSI include, the output from the include must continue from
>   the next filter along from the INCLUDES filter
>

Could this in some way be related to the bug I filed a while ago where the 
SSI output filter mangles the QUERY_STRING variable by replacing it with 
the query string used in the last include directive?

https://issues.apache.org/bugzilla/show_bug.cgi?id=49043

This behavior changed between 1.3 and 2.x and my uninformed guess is that 
this is probably a scoping issue that happened when SSI was turned into a 
filter (i.e. before the QUERY_STRING was only modified for each subrequest 
but in a filter context the changed QUERY_STRING string no basically is 
used for "all following data").

Regards,
   Dennis