[Catalyst] A different approach to static content

[Matt S Trout]

On Tue, Aug 16, 2005 at 12:29:22PM -0400, Christopher H. Laco wrote:
> I wanted to start a new thread on this topic to gather and ideas, 
> opinions, or flames about serving static content under a Catalyst 
> application.
> 
> In the current state of affairs, A Catalyst app handles all requests for 
> its app domain. This is based on cookbook examples like these 
> http://search.cpan.org/dist/Catalyst/lib/Catalyst/Manual/Cookbook.pod#Serving_with_Apache
> 
> In order to serve static content, on has to either load 
> Catalyst::Plugin::static and configure it, or add Alias/Location 
> directives to httpd.conf to have apache bypass the handler for /.
> 
> While there's nothing particularly wrong with this approach, it seems 
> rather dirty and more work that it should be. I thinks it's possible to 
> have the Catalyst app Do The Right thing, if the developer so chooses.

Why not just modify Catalyst::Plugin::Static so that it returns DECLINED
to mod_perl, thus resulting in apache defaulting through to serving the
static files statically?

> What I'd like to propose is the following [if possible]: when a Catalyst 
> app is loaded into MP via PerlModule MyCatalystApp, that the Catalyst 
> setup code dynamically adds <Location> handlers to apache for all of its 
> public actions (urls). This seems to be the best of both worlds. It only 
> handles requests the it has actions for, and apache servers static or 
> other types of contents uner lib/root like it always has; all without 
> the need to constantly tweak the httpd.conf or tweak the Static plugin.

It's potentially fragile, your apache config is suddenly part created by
something else (Cobalt RaQs dothis, it's a nightmare to debug), and I dunno
how the hell you'd manage to handle regex actions (translate to LocationMatch?
good luck ...)

Returning DECLINED to apache - or just having a <Location /myapp/static>
block when you deploy under mod_perl - seems like a much better way to do
it.

-- 
     Matt S Trout           Website: http://www.shadowcatsystems.co.uk
  Technical Director        E-mail:  mst (at) shadowcatsystems.co.uk
Shadowcat Systems Ltd.

 + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +