Rogier Peters wrote:
Guys,
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 WONTFIX.
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?
