You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2004/05/18 23:56:15 UTC
invalid content length
Can anybody tell me what can cause the invalid content length? The first
one is html serializer, the latter ones text serializer.
Joerg
23:45:16.828 WARN!! Invalid length: Content-Length=1043 written=798 for
http://127.0.0.1:8888/xfaces/test-html-mozilla-skin-simple
23:45:18.000 WARN!! Invalid length: Content-Length=919 written=186 for
http://127.0.0.1:8888/xfaces/css/html/mozilla/skin/simple/step80-pages/simple/html/common/css.css
23:45:18.000 WARN!! Invalid length: Content-Length=919 written=59 for
http://127.0.0.1:8888/xfaces/css/html/mozilla/skin/simple/step01-renderkit/html/common/css.css
Re: invalid content length
Posted by Ralph Goers <Ra...@dslextreme.com>.
We were seeing this when putting up an error page. Mysteriously, we
changed our error page and it went away. No idea why.
Ralph
Joerg Heinicke said:
> Can anybody tell me what can cause the invalid content length? The first
> one is html serializer, the latter ones text serializer.
>
> Joerg
>
>
> 23:45:16.828 WARN!! Invalid length: Content-Length=1043 written=798 for
> http://127.0.0.1:8888/xfaces/test-html-mozilla-skin-simple
>
> 23:45:18.000 WARN!! Invalid length: Content-Length=919 written=186 for
> http://127.0.0.1:8888/xfaces/css/html/mozilla/skin/simple/step80-pages/simple/html/common/css.css
>
> 23:45:18.000 WARN!! Invalid length: Content-Length=919 written=59 for
> http://127.0.0.1:8888/xfaces/css/html/mozilla/skin/simple/step01-renderkit/html/common/css.css
>
>
>
Re: invalid content length
Posted by leo leonid <te...@leonid.de>.
On 18.05.2004, at 23:56, Joerg Heinicke wrote:
> Can anybody tell me what can cause the invalid content length? The
> first one is html serializer, the latter ones text serializer.
>
> Joerg
>
>
another one is http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17370
/leo
Re: invalid content length
Posted by Joerg Heinicke <jo...@gmx.de>.
On 21.05.2004 21:36, Joerg Heinicke wrote:
>> Can anybody tell me what can cause the invalid content length?
>
> Found at least the reason: A stylesheet is imported via cocoon:/ and in
> this pipeline the stylesheet is *read* from disk, the ResourceReader
> also sets the content-length header, the 919 bytes are the length of the
> stylesheet.
> Now the question how to fix it. Referencing the stylesheet in the same
> way directly from the sitemap would result in a ProcessingException:
> "Streaming of an internal pipeline is not possible with a reader."
> (AbstractProcessingPipeline, line 678).
>
> 1st issue: That this exception is not thrown when the stylesheet is
> imported by another stylesheet via cocoon:/ is 1.) somewhat inconsistent
> and 2.) hints on a bigger problem (why is this internal request not
> recognized as an internal request?).
>
> On the one hand we could for simplification throw an exception for this
> case too - however this case will be recognized as internal request. On
> the other hand there is no need for it as transformers don't need to be
> streamed - otherwise it would not work using the reader as it did. This
> would allow to write partly shorter sitemaps, but I don't know if it's
> worth the effort to recognize internal requests sent by transformer steps.
>
> 2nd issue: Letting the reader set the headers "unasked" does not sound
> like IoC. The SitemapOutputComponent has a method
> shouldSetContentLength(), the AbstractReader implements it by returning
> false, but the ResourceReader sets it? Thinking in code smells [1] this
> stinks :)
Just another issue I want to nag you. Nobody cares or has an opinion? I
would like to have solved both issues: 1. correct recognition of
internal pipelines. 2. the reader is explicitely asked for setting the
headers or this tasks is completely removed from it and put into the
pipeline - but no auto magic.
Joerg
Re: invalid content length
Posted by Joerg Heinicke <jo...@gmx.de>.
I'm no longer the only one having problem with the issues mentioned
below: http://marc.theaimsgroup.com/?t=108558448300001&r=1&w=4.
What's interesting about this case is the correct recognition of an
internal request in PipelineUtil.processPipelineToDOM(), but not for the
older cocoon.processPipelineTo(). Shouldn't this give hints on the root
of the problem?
Joerg
On 21.05.2004 21:36, Joerg Heinicke wrote:
> On 18.05.2004 23:56, Joerg Heinicke wrote:
>
>> Can anybody tell me what can cause the invalid content length? The
>> first one is html serializer, the latter ones text serializer.
>
>
> Found at least the reason: A stylesheet is imported via cocoon:/ and in
> this pipeline the stylesheet is *read* from disk, the ResourceReader
> also sets the content-length header, the 919 bytes are the length of the
> stylesheet.
>
>> 23:45:18.000 WARN!! Invalid length: Content-Length=919 written=186
>> for
>> http://127.0.0.1:8888/xfaces/css/html/mozilla/skin/simple/step80-pages/simple/html/common/css.css
>>
>
>
> Now the question how to fix it. Referencing the stylesheet in the same
> way directly from the sitemap would result in a ProcessingException:
> "Streaming of an internal pipeline is not possible with a reader."
> (AbstractProcessingPipeline, line 678).
>
> 1st issue: That this exception is not thrown when the stylesheet is
> imported by another stylesheet via cocoon:/ is 1.) somewhat inconsistent
> and 2.) hints on a bigger problem (why is this internal request not
> recognized as an internal request?).
>
> On the one hand we could for simplification throw an exception for this
> case too - however this case will be recognized as internal request. On
> the other hand there is no need for it as transformers don't need to be
> streamed - otherwise it would not work using the reader as it did. This
> would allow to write partly shorter sitemaps, but I don't know if it's
> worth the effort to recognize internal requests sent by transformer steps.
>
> 2nd issue: Letting the reader set the headers "unasked" does not sound
> like IoC. The SitemapOutputComponent has a method
> shouldSetContentLength(), the AbstractReader implements it by returning
> false, but the ResourceReader sets it? Thinking in code smells [1] this
> stinks :)
>
> WDYT?
>
> Joerg
>
> [1] http://c2.com/cgi/wiki?CodeSmell
Re: invalid content length
Posted by Joerg Heinicke <jo...@gmx.de>.
On 18.05.2004 23:56, Joerg Heinicke wrote:
> Can anybody tell me what can cause the invalid content length? The
> first one is html serializer, the latter ones text serializer.
Found at least the reason: A stylesheet is imported via cocoon:/ and in
this pipeline the stylesheet is *read* from disk, the ResourceReader
also sets the content-length header, the 919 bytes are the length of the
stylesheet.
> 23:45:18.000 WARN!! Invalid length: Content-Length=919 written=186
> for
> http://127.0.0.1:8888/xfaces/css/html/mozilla/skin/simple/step80-pages/simple/html/common/css.css
Now the question how to fix it. Referencing the stylesheet in the same
way directly from the sitemap would result in a ProcessingException:
"Streaming of an internal pipeline is not possible with a reader."
(AbstractProcessingPipeline, line 678).
1st issue: That this exception is not thrown when the stylesheet is
imported by another stylesheet via cocoon:/ is 1.) somewhat inconsistent
and 2.) hints on a bigger problem (why is this internal request not
recognized as an internal request?).
On the one hand we could for simplification throw an exception for this
case too - however this case will be recognized as internal request. On
the other hand there is no need for it as transformers don't need to be
streamed - otherwise it would not work using the reader as it did. This
would allow to write partly shorter sitemaps, but I don't know if it's
worth the effort to recognize internal requests sent by transformer steps.
2nd issue: Letting the reader set the headers "unasked" does not sound
like IoC. The SitemapOutputComponent has a method
shouldSetContentLength(), the AbstractReader implements it by returning
false, but the ResourceReader sets it? Thinking in code smells [1] this
stinks :)
WDYT?
Joerg
[1] http://c2.com/cgi/wiki?CodeSmell