Re: possible bug in Mason 1.36

On Mon, 6 Aug 2007, Beaudet, David P. wrote:

> (1) ApacheHandler.pm, line 954: content_type('') is accepted by Apache
> as an empty string (which might be invalid in its own right, but unsure)
> and is output as an empty string when the Mason OUT method sends the
> content type via send_http_header() the first through.

An empty string is almost certainly invalid as a content type, but we're 
using it intentionally as a way to mark the request as being for a 
directory. Otherwise the content type is something like 
"httpd/unix-directory", which is probably not what you want.

A request for a directory should always be handled by a dhandler with 
Mason, and you should always set the content_type explicitly in a 
dhandler. There's actually a note about this in the docs in 
HTML::Mason::Admin under "Allowing Directory Requests".

> (2) Further down the chain, ApacheHandler.pm's http_header_sent() method
> checks the value of the "Content-Type" header against undef to see
> whether the headers were already sent and receives undef back, so the
> fact that the header was already sent with ('') as content_type is not
> registered.

It's not checking against undef, it's just checking for truth, which means 
that the empty string will be false.

> Changing line 954 from $r->content_type('') back to what it used to be
> in 1.35 $r->content_type(undef) fixes the duplicate header problem.
> There's no documentation I could find explaining why that was changed in
> 1.36.

The reason was that passing undef to this method caused a "Use of 
unitialized value in subroutine".

I'm not sure what's happening with Bricolage, but I cannot reproduce this 
doubled header problem in my tests. Can you provide a simple test case? Or 
maybe the problem is that Bricolage has a dhandler which is not setting 
the content type explicitly.


-dave

/*===================================================
VegGuide.Org                        www.BookIRead.com
Your guide to all that's veg.       My book blog
===================================================*/

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/