You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by bu...@apache.org on 2003/11/07 11:00:31 UTC

DO NOT REPLY [Bug 17370] - Wrong HTTP Content Length for Reader when "show-time"

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17370>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17370

Wrong HTTP Content Length for Reader when "show-time"

cziegeler@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From cziegeler@apache.org  2003-11-07 10:00 -------
It is not possible to fix this problem as once the content length is written it 
can't be changed later on. So if e.g. the content comes from the cache, the 
cache sets the content length and this can't be overwritten anymore. These are 
the times, where it goes wrong - the same applies to the reader.
But as "show-time" is only a debugging feature, this is not a real problem, so 
we set it to "WONTFIX".
I will add a comment to web.xml about it though.

Re: DO NOT REPLY [Bug 17370] - Wrong HTTP Content Length for Reader when "show-time"

Posted by Joerg Heinicke <jh...@virbus.de>.
On 07.11.2003 19:10, Stefano Mazzocchi wrote:

>>> But it might not worth the trouble adding all this complexity just to
>>> implement some debug feature
>>
>>
>> Well, it obviously is a debug feature. But you probably
>> might want to look at it as a small, discreet marketing
>> feature also. I suppose some IT-oriented people view
>> the page source to see the quality of html code
>> or to find out "how" was the page construted/generated.
>> And don't forget the show-time feature prints not only
>> the processing time, but also the Apache Cocoon mark.
>>
>> (<!-- Processed by Apache Cocoon 2.2... -->)
>>
>> That's a common practice used in many frameworks/producs
>> ex Vignette products etc.
> 
> 
> FYI, cocoon already outputs a "X-cocoon:" HTTP header that "markets" our 
> presence in every request it handles. So, if we really want to know if 
> cocoon handles that resource look at the HTTP headers, they don't break 
> content length and are much more "REST"-ish.

But this can be shadowed/hidden by a web server. I never investigated 
why, but our applications running on Cocoon don't have this header. So I 
guess it's the web server (Apache in this case).

Joerg


Re: DO NOT REPLY [Bug 17370] - Wrong HTTP Content Length for Reader when "show-time"

Posted by Joerg Heinicke <jh...@virbus.de>.
On 07.11.2003 19:31, Tony Collen wrote:

>>> FYI, cocoon already outputs a "X-cocoon:" HTTP header that "markets"
>>> our presence in every request it handles. So, if we really want to
>>> know if cocoon handles that resource look at the HTTP headers, they
>>> don't break content length and are much more "REST"-ish.
>>
>>
>>
>> I know about header add of course, but as I suppose amout of people
>> that can lookup HTTP headers is just vestigal in comparison to
>> amount of people that are able to lookup the HTML source.
>> That's just my 2 cents.
>>
> 
> IMO as soon as this gets added, someone will want it turned off (like 
> me), and then we're back at ground zero.    Best to leave it as a 
> header, I think.

It's optional - even now. There is only a problem with the content 
length header when using this feature.

Joerg


Re: DO NOT REPLY [Bug 17370] - Wrong HTTP Content Length for Reader when "show-time"

Posted by Tony Collen <co...@umn.edu>.
Tomasz Nowak wrote:
> Stefano Mazzocchi <st...@apache.org> wrote:


<snip/>

>>FYI, cocoon already outputs a "X-cocoon:" HTTP header that "markets"
>>our presence in every request it handles. So, if we really want to
>>know if cocoon handles that resource look at the HTTP headers, they
>>don't break content length and are much more "REST"-ish.
> 
> 
> I know about header add of course, but as I suppose amout of people
> that can lookup HTTP headers is just vestigal in comparison to
> amount of people that are able to lookup the HTML source.
> That's just my 2 cents.
> 

IMO as soon as this gets added, someone will want it turned off (like me), and then we're back at 
ground zero.    Best to leave it as a header, I think.

Tony


Re: DO NOT REPLY [Bug 17370] - Wrong HTTP Content Length for Reader when "show-time"

Posted by Tomasz Nowak <tn...@netventure.pl>.
Stefano Mazzocchi <st...@apache.org> wrote:
>
> On 7 Nov 2003, at 18:30, Tomasz Nowak wrote:
> 
> > Vadim Gritsenko <va...@verizon.net> wrote:
> > > 
> > > But it might not worth the trouble adding all this complexity
> > > just to implement some debug feature
> > 
> > Well, it obviously is a debug feature. But you probably
> > might want to look at it as a small, discreet marketing
> > feature also. I suppose some IT-oriented people view
> > the page source to see the quality of html code
> > or to find out "how" was the page construted/generated.
> > And don't forget the show-time feature prints not only
> > the processing time, but also the Apache Cocoon mark.
> > 
> > (<!-- Processed by Apache Cocoon 2.2... -->)
> > 
> > That's a common practice used in many frameworks/producs
> > ex Vignette products etc.
> 
> FYI, cocoon already outputs a "X-cocoon:" HTTP header that "markets"
> our presence in every request it handles. So, if we really want to
> know if cocoon handles that resource look at the HTTP headers, they
> don't break content length and are much more "REST"-ish.

I know about header add of course, but as I suppose amout of people
that can lookup HTTP headers is just vestigal in comparison to
amount of people that are able to lookup the HTML source.
That's just my 2 cents.

-- 
Tomasz Nowak



Re: DO NOT REPLY [Bug 17370] - Wrong HTTP Content Length for Reader when "show-time"

Posted by Stefano Mazzocchi <st...@apache.org>.
On 7 Nov 2003, at 18:30, Tomasz Nowak wrote:

> Vadim Gritsenko <va...@verizon.net> wrote:
>>
>> But it might not worth the trouble adding all this complexity just to
>> implement some debug feature
>
> Well, it obviously is a debug feature. But you probably
> might want to look at it as a small, discreet marketing
> feature also. I suppose some IT-oriented people view
> the page source to see the quality of html code
> or to find out "how" was the page construted/generated.
> And don't forget the show-time feature prints not only
> the processing time, but also the Apache Cocoon mark.
>
> (<!-- Processed by Apache Cocoon 2.2... -->)
>
> That's a common practice used in many frameworks/producs
> ex Vignette products etc.

FYI, cocoon already outputs a "X-cocoon:" HTTP header that "markets" 
our presence in every request it handles. So, if we really want to know 
if cocoon handles that resource look at the HTTP headers, they don't 
break content length and are much more "REST"-ish.

--
Stefano.


Re: DO NOT REPLY [Bug 17370] - Wrong HTTP Content Length for Reader when "show-time"

Posted by Tomasz Nowak <tn...@netventure.pl>.
Vadim Gritsenko <va...@verizon.net> wrote:
>
> But it might not worth the trouble adding all this complexity just to
> implement some debug feature

Well, it obviously is a debug feature. But you probably
might want to look at it as a small, discreet marketing
feature also. I suppose some IT-oriented people view
the page source to see the quality of html code
or to find out "how" was the page construted/generated.
And don't forget the show-time feature prints not only
the processing time, but also the Apache Cocoon mark.

(<!-- Processed by Apache Cocoon 2.2... -->)

That's a common practice used in many frameworks/producs
ex Vignette products etc.

-- 
Tomasz Nowak



RE: DO NOT REPLY [Bug 17370] - Wrong HTTP Content Length for Reader when "show-time"

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
> 
> bugzilla@apache.org wrote:
> 
> >Wrong HTTP Content Length for Reader when "show-time"
> >  
> >
> ...
> 
> >It is not possible to fix this problem as once the content 
> length is written it 
> >can't be changed later on. So if e.g. the content comes from the 
> cache, the 
> >cache sets the content length and this can't be overwritten 
> anymore. These are 
> >the times, where it goes wrong - the same applies to the reader.
> >But as "show-time" is only a debugging feature, this is not a 
> real problem, so 
> >we set it to "WONTFIX".
> >  
> >
> 
> There is a way to fix it: Wrap response, and when content length is set 
> add a fixed amount (equal to max length of time string) to it to reserve 
> space for the time string. Once time string is written, add some padding 
> so actual content length matches advertised.
> 
> 
> But it might not worth the trouble adding all this complexity just to 
> implement some debug feature
> 
Yes, I thought about this as well - but as you said, imho it's not worth
the effort. And there is another problem, the time is only written for 
html pages, but it might be that you don't know if it's an html page
when the content length is set and you can only return "-1" as the
length.

Carsten

Re: DO NOT REPLY [Bug 17370] - Wrong HTTP Content Length for Reader when "show-time"

Posted by Vadim Gritsenko <va...@verizon.net>.
bugzilla@apache.org wrote:

>Wrong HTTP Content Length for Reader when "show-time"
>  
>
...

>It is not possible to fix this problem as once the content length is written it 
>can't be changed later on. So if e.g. the content comes from the cache, the 
>cache sets the content length and this can't be overwritten anymore. These are 
>the times, where it goes wrong - the same applies to the reader.
>But as "show-time" is only a debugging feature, this is not a real problem, so 
>we set it to "WONTFIX".
>  
>

There is a way to fix it: Wrap response, and when content length is set 
add a fixed amount (equal to max length of time string) to it to reserve 
space for the time string. Once time string is written, add some padding 
so actual content length matches advertised.


But it might not worth the trouble adding all this complexity just to 
implement some debug feature

Vadim