Vadim Gritsenko wrote:<snip/>
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
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
