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).
(RT#50082)
SSI used to work, but actually, unfortunately, used to work _entirely
coincidentally_..
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..
Cheers
t0m
_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
