cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Using cocoon: source in <xsl:import>s
Date Thu, 21 Aug 2003 11:34:02 GMT
Sylvain Wallez wrote:

> Carsten Ziegeler wrote:
>> Vadim Gritsenko wrote:
>>> Phil Shafer wrote:
>>>> Vadim Gritsenko writes:
>>>>> Try the suggestion above.
>>>> Will do. Thanks for the help. Is there a PR open for this? Should
>>>> I open one?
>>> I think there is no bug open for this. Also, I'd ping Carsten to 
>>> hear his opinion. Carsten?
>>> PS Thread:
>> Pong.
>> 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.

Actually it depends not on header type alone but on usage of the 
resource. If it is aggregated to be part of the output - then I agree 
with some of your thoughts below. But if it is, say, called from the 
flow - none of headers should make it into the actual response. Another 
example I could make is authentication action which authenticates 
against cocoon:/ resource. No response headers of internal request 
should affect actual login page response.


> For example :
> - content-length : only the top-level request handling can set it (as 
> shown by the current problem)
> - expires : any request (internal or external) can set it, but only 
> the lowest delay is kept
> - vary : the final header should contain all the vary headers set by 
> all requests (ex : language, user-agent, etc)
> 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 ?
> Sylvain

View raw message