Vadim Gritsenko wrote:
Phil Shafer wrote:Pong.
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
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.
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
-- 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
