[Catalyst] Re: Problem using Static::Simple
On 19/09/2007, Will Hawes [EMAIL PROTECTED] 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 ) = @_;
$c-response-status(404);
$c-response-body( 'not found' );
}
3) $ PATH_INFO=/static1 perl MyApp/script/myapp_cgi.pl
Content-Length: 9
Content-Type: text/html; charset=utf-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=15, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=utf-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=/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. Accessing 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=15, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/x-perl
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?
*BUMP*
Anyone?
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Problem using Static::Simple
On Sep 20, 2007, at 5:50 AM, Will Hawes wrote:
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 = ( $dir =~ 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 = ( $dir =~ 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?
Yes both of these are bugs, I will get them fixed shortly.
Thanks,
-Andy
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Problem using Static::Simple
On Sep 20, 2007, at 5:50 AM, Will Hawes wrote:
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 = ( $dir =~ 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 = ( $dir =~ 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?
I've pushed Static::Simple 0.20 with these fixes. URLs like /static1
in your case will now be handled by Cat instead of S::S and 404 will
have a text/html content-type.
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Problem using Static::Simple
On 24/09/2007, Andy Grundman [EMAIL PROTECTED] wrote: I've pushed Static::Simple 0.20 with these fixes. URLs like /static1 in your case will now be handled by Cat instead of S::S and 404 will have a text/html content-type. Thanks Andy, much appreciated. ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Problem using Static::Simple
On 19/09/2007, Will Hawes [EMAIL PROTECTED] wrote:
On 19/09/2007, Will Hawes [EMAIL PROTECTED] 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 ) = @_;
$c-response-status(404);
$c-response-body( 'not found' );
}
3) $ PATH_INFO=/static1 perl MyApp/script/myapp_cgi.pl
Content-Length: 9
Content-Type: text/html; charset=utf-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=15, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=utf-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=/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. Accessing
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=15, max=99
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 = ( $dir =~ 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 = ( $dir =~ 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?
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Problem using Static::Simple
On 19/09/2007, Will Hawes [EMAIL PROTECTED] 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 ) = @_;
$c-response-status(404);
$c-response-body( 'not found' );
}
3) $ PATH_INFO=/static1 perl MyApp/script/myapp_cgi.pl
Content-Length: 9
Content-Type: text/html; charset=utf-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=15, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=utf-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=/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. Accessing 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=15, max=99
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?
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
