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 14:58:24 GMT
Vadim Gritsenko wrote:

> Sylvain Wallez wrote:
>> Vadim Gritsenko wrote:


>>> 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? :) 

Hehe, so the same applies to your authentication pipeline example ;-)

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

Don't know if dropping them is really on the safer side : what if an 
internal pipeline depends on the local or the user agent and this is not 
mentioned in the headers ? Proxy servers will improperly cache it for 
any locale/browser...


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

View raw message