On 16 Apr 2010, at 01:53, Jason McIntosh wrote:

Howdy y'all,

Since upgrading to Catalyst 5.8022 on Wednesday, I've found that no
Catalyst requests coming from Apache server-side includes work.

If the user requests "foo.shtml", and that file contains "<!--#include
virtual="/catalyst/header" -->", then Apache correctly forwards the
request to my Catalyst FCGI. However, Catalyst now thinks that the
request path is "foo.shtml" instead of "/catalyst/header", and
responds with my app's 404-ey default action.

It didn't have this problem before the upgrade. Any thoughts or advice
would be kindly appreciated!

(Some folks on #catalyst IRC mentioned that there might be a fix for
this currently underway. But, Google is mum on it, as are the list
archives, so I thought it worth bringing up here anyway.)
Yes, this is due to the change in 5.80015:

- Set $ENV{PATH_INFO} from $ENV{REQUEST_URI} combined with
$ENV{SCRIPT_NAME} if possible. This is many web servers always fully
decode PATH_INFO including URI reserved characters. This allows us to
tell foo%2cbar from foo%252cbar, and fixes issues with %2F in paths
being incorrectly decoded, resulting in too many path parts (rather
than 1 path part containing a /, on some web servers (at least nginx).
SSI used to work, but actually, unfortunately, used to work _entirely
The change causes a whole load of other issues, and generally opens a
can of worms.
I'll provide a more detailed explanation to everyone shortly, but
suffice to say that this is known about and I am working/thinking on
fixing it / how to fix it..

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 9 | next ›
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedApr 16, '10 at 12:53a
activeApr 18, '10 at 11:47p



site design / logo © 2021 Grokbase