FAQ
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.)

--
Jason McIntosh

http://jmac.org ? jmac@jmac.org ? @JmacDotOrg

Search Discussions

  • Jay Shirley at Apr 16, 2010 at 1:18 am

    On Thu, Apr 15, 2010 at 5:53 PM, 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.)

    Did you upgrade anything else (Apache?) or just Catalyst? Any other
    changes, configuration or anything?

    -J
  • Jason McIntosh at Apr 16, 2010 at 2:03 am

    On Thu, Apr 15, 2010 at 9:18 PM, J. Shirley wrote:
    Did you upgrade anything else (Apache?) or just Catalyst? ?Any other
    changes, configuration or anything?
    Nothing that strikes me as relevant. Also upgraded Moose and DBIC and
    various other Perl modules that all this stuff wanted, but Apache (and
    everything else on the system) stayed put.

    --
    Jason McIntosh

    http://jmac.org ? jmac@jmac.org ? @JmacDotOrg
  • Jay Shirley at Apr 16, 2010 at 2:19 am

    On Thu, Apr 15, 2010 at 7:03 PM, Jason McIntosh wrote:
    On Thu, Apr 15, 2010 at 9:18 PM, J. Shirley wrote:

    Did you upgrade anything else (Apache?) or just Catalyst? ?Any other
    changes, configuration or anything?
    Nothing that strikes me as relevant. Also upgraded Moose and DBIC and
    various other Perl modules that all this stuff wanted, but Apache (and
    everything else on the system) stayed put.
    What version wee you upgrading from? There's been some changes to
    that code in the various 5.8 releases.

    Also, can you share your relevant FCGI config?

    Thanks,
    -J
  • Ashley Pond V at Apr 16, 2010 at 3:49 am
    It's a longshot that this is relevant to the problem but it is
    relevant to Engine::CGI and I needed an excuse to bring it up again.
    There is a long-standing bug in the prepare_path of
    Catalyst::Engine::CGI that wrecks certain kinds of apache path
    handling (and therefore uri_for) if the path contains regex chars.

    http://www.gossamer-threads.com/lists/catalyst/dev/21380
    http://rt.cpan.org/Public/Bug/Display.html?id$951

    Due to the timing of 5.7 freezing, my trepidation with messing with
    5.8 at the time, I never redid the patch and tests. I don't have the
    tuits now, just bumping it on the list and hijacking threads because
    I'm so that way.

    -Ashley
    On Apr 15, 2010, at 7:19 PM, J. Shirley wrote:
    On Thu, Apr 15, 2010 at 7:03 PM, Jason McIntosh wrote:
    On Thu, Apr 15, 2010 at 9:18 PM, J. Shirley <jshirley@gmail.com>
    wrote:
    Did you upgrade anything else (Apache?) or just Catalyst? Any other
    changes, configuration or anything?
    Nothing that strikes me as relevant. Also upgraded Moose and DBIC and
    various other Perl modules that all this stuff wanted, but Apache
    (and
    everything else on the system) stayed put.
    What version wee you upgrading from? There's been some changes to
    that code in the various 5.8 releases.

    Also, can you share your relevant FCGI config?

    Thanks,
    -J

    _______________________________________________
    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/
  • Tomas Doran at Apr 18, 2010 at 11:06 pm

    On 16 Apr 2010, at 04:49, Ashley wrote:

    It's a longshot that this is relevant to the problem but it is
    relevant to Engine::CGI and I needed an excuse to bring it up again.
    There is a long-standing bug in the prepare_path of
    Catalyst::Engine::CGI that wrecks certain kinds of apache path
    handling (and therefore uri_for) if the path contains regex chars.

    http://www.gossamer-threads.com/lists/catalyst/dev/21380
    http://rt.cpan.org/Public/Bug/Display.html?id$951

    Due to the timing of 5.7 freezing, my trepidation with messing with
    5.8 at the time, I never redid the patch and tests. I don't have the
    tuits now, just bumping it on the list and hijacking threads because
    I'm so that way.
    No, that's cool..

    That bug was resolved as I couldn't reproduce it in any way, and I
    neglected to pay (enough) attention to the the last paragraph :(

    I can entirely see and reproduce the 2nd issue in that ticket, and I
    have now fixed it:

    http://dev.catalyst.perl.org/svnweb/Catalyst/revision/?rev166

    Thanks for the (re-)report.

    Cheers
    t0m
  • Jason McIntosh at Apr 16, 2010 at 2:21 pm

    On Thu, Apr 15, 2010 at 10:19 PM, J. Shirley wrote:
    What version wee you upgrading from? ?There's been some changes to
    that code in the various 5.8 releases.
    Upgraded from 5.7015. Through experimentation last night I confirmed
    that this problem stops happening if I downgrade Catalyst to 5.71001
    -- the last of the 5.7 line, according to CPAN. (Of course, since I
    upgraded so many dependent modules as well, not much else works
    besides it, sigh.)

    Have tried with various earlier 5.8s and they all exhibit the same
    problem. (The earliest 5,8s fail to work with the new Moose I have
    installed, and I didn't dig deeper.)
    Also, can you share your relevant FCGI config?
    Not sure what you want to see? I have Catalyst running as an external
    process, like so:

    FastCgiExternalServer /tmp/fcgi-example.org -socket
    /var/run/mmn/fcgi-example.org.socket

    This configuration hasn't changed in a year or more. (Apologies for
    the "example.org" subterfuge; it's a client's website.) And, as I
    said, "ordinary" user-directed requests work great. Apache SSI works
    too, as far as Apache is concerned -- it's just that Catalyst 5.8
    seems to misinterpret the URI of the request, when it's called by an
    SSI.

    --
    Jason McIntosh

    http://jmac.org ? jmac@jmac.org ? @JmacDotOrg
  • Tomas Doran at Apr 18, 2010 at 11:19 pm

    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
  • Jason McIntosh at Apr 18, 2010 at 11:47 pm

    On Sun, Apr 18, 2010 at 7:19 PM, Tomas Doran wrote:
    Yes, this is due to the change in 5.80015:
    ...and rolling my installed version back to 5.80014 does indeed make
    my problem go away. (As you suggested it would, over on #catalyst a
    couple of days ago.)

    Thanks again for the ack, and the work into fixing this.

    --
    Jason McIntosh

    http://jmac.org ? jmac@jmac.org ? @JmacDotOrg

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedApr 16, '10 at 12:53a
activeApr 18, '10 at 11:47p
posts9
users4
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2021 Grokbase