Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Phil Shafer wrote:
Vadim Gritsenko writes:I think there is no bug open for this. Also, I'd ping Carsten to hear his opinion. Carsten?
Try the suggestion above.
Will do. Thanks for the help. Is there a PR open for this? Should I open one?
PS Thread: http://marc.theaimsgroup.com/?t=106067513100007&r=1&w=2
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.
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.
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 ?
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
