Sylvain Wallez wrote:
Vadim Gritsenko wrote:
<snip/>
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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
