cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
Subject Re: Using cocoon: source in <xsl:import>s
Date Thu, 21 Aug 2003 14:44:27 GMT
Sylvain Wallez wrote:

> Vadim Gritsenko wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Carsten Ziegeler wrote:
>>
<snip/>

>>>> 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.
>
>
>
> Mmmh... yep, it seems this problems is tricky ;-)
>
> So propagation of headers depends on the fact that the request 
> "participates" to the building of the final response, meaning its 
> result can be found in some way to what is sent to the browser, e.g. 
> through aggregation, xinclude, internal redirects.
>
> How can we determine this ? I'm not sure this can be determined 
> automatically. For example, the headers set by the "src" of 
> FileGenerator can be propagated, while those of the "src" of 
> TraxTransformer should not.


Why it shouldn't? If source of XSLT transformation "Expires:" in one 
hour, that means that result of this transformation is also expires in 
the same one hour, right? :)


> And leaving this decision to the caller of SourceResolver.resolve() 
> doesn't seem to be the solution, as it opens the doors to both 
> omissions and abuses.
>
> Any idea ?


I'd suggest to always drop the headers. Just to be on the safer side. 
And then think / come up with other solution. If required.

Vadim



Mime
View raw message