Sylvain Wallez wrote:
Yes, I agree.This reminds me some random thoughts I had with Gianugo around a beerI 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.
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.
Having a filter is a good idea, but the top-level environment does notThe 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 ?
know if the one setting the header is a sub environment or if it is
comming from the current request.
So I guess, we have to make a response wrapper and use the filter inbetween.
You're right. The solution can then be that for each header we can define the propagation policy (should a sub environment transmit the setHeader() call to its parent ?) and a filtering that's applied by the toplevel environment (min, max, concat, etc).
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
