cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Using cocoon: source in <xsl:import>s
Date Thu, 21 Aug 2003 07:51:45 GMT
Carsten Ziegeler wrote:

>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
>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.

You're right. The solution can then be that for each header we can 
define the propagation policy (should a sub environment transmit the 
setHeader() call to its parent ?) and a filtering that's applied by the 
toplevel environment (min, max, concat, etc).


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message