cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <>
Subject Re: Invalid content length, revisited
Date Fri, 15 Oct 2004 11:07:42 GMT
Rogier Peters wrote:

>On 18/5 Joerg asked a question about invalid content length errors[1] due to
>readers. There is also a bug that is somewhat related[2], but it seems to be

The WONTFIX seems to apply to the original description of the bug only. 
There is a related issue that is mentioned in that thread that I think 
*is* a valid problem.

>I have the following case :
>  generator    reader
>      |          |
>  validator .. dtd
>      |
>  serializer
>In this case the reader sets the content-length, and the serializer doesn't. So
>if the length of the serializer's output is greater than that of the dtd, output
>is incomplete.
>Althoug a quick fix is not to get the dtd through a reader, I'm sure there are
>cases where that isn't a solution. 
>I didn't post this as a bug, yet, because I am not sure whether this is just
>unintended use of the reader. 

It oughta work. I don't see how it doesn't. The environment that is 
associated with internal requests (EnvironmentWrapper) does not forward 
setContentLength() to its wrapped instance so it shouldn't reach the 
HttpEnvironment. Perhaps reading a cocoon pipeline is interpreted as an 
internal redirect in wich case MutableEnvironmentFacade *does* forward it?

>Also, I can't quite get my mind around what's the best way to solve this. Joerg
>suggested in his original mail[1] to build some awareness in to the reader to
>see if it is called as a cocoon-source or not. Another possible solution would
>be setting content-length from all serializers, although Carsten suggests in the
>closing of the bug that content-length can not be set repeatedly. 

The problem Carsten mentions is that once the http headers are sent 
setting the content-length header has no effect.

I agree with Joerg that it smells that the (resource) reader is setting 
all kinds of response headers where it should probably better be handled 
by the processing pipeline. That is the IoC approach that is taken with 
setting the Content-Type header. By doing it in that way, you avoid the 
current problem that a ResourceReader in a caching pipeline produces 
different responses depending on whether the content is served from the 
cache or produced by a call to generate().

So perhaps we should think about enhancing the SitemapOutputComponent 
interface with several additional methods to allow the processing 
pipeline to set more response headers. I know of one problem with 
content encoding where the pipeline should be able to determine the 
encoding in order to return it in the Content-Type header.

What do others think?

View raw message