Re: possible bug in Mason 1.36

On Sun, 19 Aug 2007, David E. Wheeler wrote:

> Well, we set the content type in Apache, rather than Mason. Our Apache 
> handler has ($ah is the Mason ApacheHandler):
>
>   eval {
>       # Prevent browsers from caching pages.
>       $r->no_cache(1);
>       # Set up the language and content type headers.
>       $r->content_languages([$lang_name]);
>       $r->content_type('text/html; charset=' . lc $char_set);
>       Bric::Util::Pref->use_user_prefs(1);
>
>       # Start the database transactions.
>       begin(1);
>       # Handle the request.
>       $status = $ah->handle_request($r);
>       # Commit the database transactions.
>       commit(1);
>
>       Bric::Util::Pref->use_user_prefs(0);
>   };
>
> IIRC, we did this so that the dhandlers wouldn't have to, as we have a lot of 
> dhandlers and, at the time we wrote Bricolage, served nothing but HTML. So 
> could this be causing the problem? I'd like to keep the setting of the 
> content-type central like this, if possible.

Hmm, this is weird. I don't see how this would've worked before, since 
Mason would've overridden the content type when the request was for a 
directory. And I definitely don't see why this would break after upgrading 
Mason to 1.36, since that hasn't fundamentally changed.


-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/