Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <dev@cocoon.apache.org>
Subject: RE: Using cocoon: source in <xsl:import>s
Date: Thu, 21 Aug 2003 08:09:52 +0200
Message-ID: <LKENJPKDAIKAPKHEOCMMCEGAEMAA.cziegeler@s-und-n.de>
MIME-Version: 1.0
In-Reply-To: <3F43702B.6040302@anyware-tech.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"

Sylvain Wallez wrote:
> >I think this is something the internal processing should handle, which
> >means, if the reader sets such a header it should simply be ignored
> >instead of being passed on.
> >Now, I guess this is very easy as we could create a response wrapper
> >for internal requests (we already have a request wrapper) and filter
> >the headers.
> >
>
> This reminds me some random thoughts I had with Gianugo around a beer
> last february : we were discussing the ability for internal sources to
> set response headers and came to the conclusion that there was no yes/no
> rule for all headers, and that the behaviour was dependent on the header
> type.
Yes, I agree.

>
>
> The solution we came to was to associate HeaderFilter components to each
> of the headers for which filtering is necessary. These filters would be
> attached to the top-level environment (i.e. the HttpEnvironment),
> receiving any setHeader call of all subenvironments handling the request.
>
> What do you think ?
>
Having a filter is a good idea, but the top-level environment does not
know if the one setting the header is a sub environment or if it is
comming from the current request.
So I guess, we have to make a response wrapper and use the filter inbetween.

Carsten