Vadim Gritsenko wrote:
Unico Hommes wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
Oh I see now. The ResourceReader also sets the content length on the response. It *really* shouldn't do that IMHO. Anybody know why it does that?
I see that EnvironmentWrapper ignores set content length. And it has RequestWrapper. BUT IT DOES NOT HAVE ResponseWrapper! I guess that's the real problem.
ResourceReader probably should be changed to set content length on the environment, but this is fix in only one case. ResponseWrapper seems to be the fix for all cases at once. Or, am I missing something?
What about FOM though? Doesn't a flowscript run within an EnvironmentWrapper? If so, having WrapperResponse ignore calls to setHeader() and related methods would be undesirable.
Shouldn't it / could it run under MutableEnvironmentFacade?
I think that in the following scenario there will be an EnvironmentWrapper in there somewhere:
sitemap --------
<map:match pattern="bar"> <map:generate src="bar"/> <map:serialize/> </map:match>
<map:match pattern="foo"> <map:call function="foo"/> </map:match>
<map:match pattern="foobar"> <map:generate src="cocoon:/foo"/> <map:serialize/> </map:match>
flowscript ----------
function foo() { cocoon.response.setHeader("foo", "bar"); cocoon.sendPage("bar"); }
Because function foo() is called via a SitemapSource its environment is a WrappedEnvironment (don't know, but I am guessing) and the call to setHeader will be to WrappedResponse?
But that is good! foo should *not* set content length in this scenario - you have further processing to do on the SAX events (in this case -- default serializer) - and content length *will* be different after pipeline is complete.
I tried to find an example of a http/1.1 header that does not depend on the top level processing environment but didn't find one. So I guess you are right that it is a good thing foo() cannot set headers. OK, I guess we should implement the WrappedResponse solution then. Any other opinions?
-- Unico
