[Catalyst] Re: Problem using Static::Simple

[Will Hawes]

On 19/09/2007, Will Hawes <wdhawes at gmail.com> wrote:
>
> On 19/09/2007, Will Hawes <wdhawes at gmail.com> wrote:
> > Having upgraded all Catalyst modules to their latest versions today, I
> think I'm seeing strangeness with Static::Simple. I've boiled it down to =
the
> following:
> >
> > 1) $ catalyst.pl MyApp
> >
> > 2) Modify MyApp::Controller::Root::default() as follows:
> >
> > sub default {
> >   my( $self, $c ) =3D @_;
> >   $c->response->status(404);
> >   $c->response->body( 'not found' );
> > }
> >
> > 3) $ PATH_INFO=3D/static1 perl MyApp/script/myapp_cgi.pl
> > Content-Length: 9
> > Content-Type: text/html; charset=3Dutf-8
> > Status: 404
> >
> > not found
> >
> > When accessing the app through Apache using Firefox with the
> LiveHTTPHeaders extension, the response headers are reported as follows:
> >
> >  HTTP/1.x 404 OK
> > Date: Wed, 19 Sep 2007 17:48:48 GMT
> > Server: Apache/2.0.55 (Ubuntu) ...
> > X-Catalyst: 5.7010
> > Content-Length: 9
> > Keep-Alive: timeout=3D15, max=3D99
> > Connection: Keep-Alive
> > Content-Type: text/html; charset=3Dutf-8
> >
> > 4) Modify myapp.yml as follows (the intention being to serve static
> files from /var/www/static/*):
> >
> > static:
> >   dirs: [ 'static' ]
> >   include_path: [ '/var/www' ]
> >
> > 5) $ PATH_INFO=3D/static1 perl MyApp/script/myapp_cgi.pl
> > Status: 404
> >
> > Note that the Catalyst-generated Content-Length and Content-Type
> response headers, as well as the response body, have disappeared. Accessi=
ng
> the script via Firefox with LiveHTTPHeaders now shows the following:
> >
> > HTTP/1.x 404 OK
> > Date: Wed, 19 Sep 2007 17:48:17 GMT
> > Server: Apache/2.0.55 (Ubuntu) ...
> > X-Catalyst: 5.7010
> > Keep-Alive: timeout=3D15, max=3D99
> > Connection: Keep-Alive
> > Transfer-Encoding: chunked
> > Content-Type: text/x-perl
>
> Forgot to mention, these response headers cause Firefox to try to
> download a PL file.
>
> > I'd have thought a request for "/static1" should be ignored by
> Static::Simple using the above config and that only URLs like "/static/1"
> should be treated as pointing to static content.
> >
> > Have I misunderstood something?
> >
>

I've dug around for a while in Catalyst::Plugin::Static::Simple, here's what
I've found:

1) The unexpected matching of URLs like "/static1" (as well as the expected
"/static/1") seems to be because no trailing slash is used in the regular
expression that performs the match:

my $re =3D ( $dir =3D~ m{^qr/}xms ) ? eval $dir : qr/^${dir_re}/;

Perhaps this is by design, but adding the trailing slash to appears to fix
the problem while still allowing files to be served from the specified
static directories:

my $re =3D ( $dir =3D~ m{^qr/}xms ) ? eval $dir : qr/^${dir_re}\//;

I assume the trailing slash could be added to each item in "dirs" in my
config to achieve the same effect. I haven't tested that but even if there's
a good reason not to modify the regex, I think the behaviour should be
documented in ::Static::Simple.

2) When a non-existent static file is requested, Firefox tries to download a
PL file rather than displaying a 404 message. This appears to be because
::Static::Simple sets $c->res->status to 404, but does not set a content
type. This causes content-type to be auto-detected as "text/x-perl", which
in turn makes Firefox want to download the file. Hacking ::Static::Simple to
set $c->res->content_type manually to "text/html" fixes the problem.

I can't see why the standard behaviour in either case above would be by
design. Are these valid problems I've highlighted and what do you think of
the suggested fixes?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20070920/eb12e=
da9/attachment.htm