cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <un...@hippo.nl>
Subject Re: Invalid content length, revisited
Date Fri, 15 Oct 2004 14:46:02 GMT
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


Mime
View raw message