Sylvain Wallez wrote: > >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. Yes, I agree.
> > > 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 ? > Having a filter is a good idea, but the top-level environment does not 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. Carsten
