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.
Vadim
For example :
- content-length : only the top-level request handling can set it (as shown by the current problem)
- expires : any request (internal or external) can set it, but only the lowest delay is kept
- vary : the final header should contain all the vary headers set by all requests (ex : language, user-agent, etc)
The solution we came to was to associate HeaderFilter components to each of the headers for which filtering is necessary. These filters would be attached to the top-level environment (i.e. the HttpEnvironment), receiving any setHeader call of all subenvironments handling the request.
What do you think ?
Sylvain
