FAQ
I've used an IIS hack engine for a good while, and finally got around to
switching to the main C::E::FastCGI with a few issues.

1. It works fine, apparently on IIS5
2. It does not work, at least not the way I have it configured, on IIS6

The issue revolves around the IIS handling of some request parameters; I
get:

PATH_INFO: /m3analyst/arm.fcgi/index
PATH_TRANSLATED: C:\Sites\ARM\arm.fcgi\index
SCRIPT_NAME: /m3analyst/arm.fcgi

Problem #1 - the condition is: ( $env->{SERVER_SOFTWARE} =~
/IIS\/[6-9]\.[0-9]/ )

This seems to explain why IIS5 is not affected in the same way. The
FastCGI component works just fine on IIS5, so I guess this ought to be
included/processed.

Problem #2 - FastCGI engine cannot handle IIS with file extension mapped
configuration for FastCGI

Obviously, IIS is broken with respect to some request parameters.

The algorthm for fixing IIS appears to be to pop items off a split
PATH_INFO and a split PATH_TRANSLATED as long as they are the same,
unshifting (!) the consistent items into a new value for PATH_INFO.
Whatever was left on the old PATH_INFO is put into SCRIPT_NAME. The
result of my request above, therefore, is:

PATH_INFO = /arm.fcgi/index
SCRIPT_NAME = /m3analyst

Since this is incorrect against the namespacing, Catalyst hits the
default action for everything.

This ought to be:

PATH_INFO = /index
SCRIPT_NAME = /m3analyst/arm.fcgi

My hacky IIS engine did a rather simpler:

my $path = $env{PATH_INFO};
my $script = $env{SCRIPT_NAME};
my $length = length($script);
if (substr($path, 0, $length) eq $script) {
$env{PATH_INFO} = substr($path, $length);
}

i.e., I left SCRIPT_NAME alone, but removed it from the front of
PATH_INFO when it matched exactly.

The documentation implies that a wildcard mapping is recommended
(although this is not supported by IIS5). I suspect the algorithm is
completely correct on IIS6/7 with a wildcard mapping.

Is this likely to require a patch to allow FastCGI to work with file
extension mapping? Shall I write one?

All the best
Stuart
--
Stuart Watt
ARM Product Developer
Information Balance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20091218/0c5771d5/attachment.htm

Search Discussions

  • Tomas Doran at Dec 18, 2009 at 7:06 pm

    On 18 Dec 2009, at 17:28, Stuart Watt wrote:
    The documentation implies that a wildcard mapping is recommended
    (although this is not supported by IIS5). I suspect the algorithm is
    completely correct on IIS6/7 with a wildcard mapping.
    Sounds like a reasonable conclusion.
    Is this likely to require a patch to allow FastCGI to work with file
    extension mapping? Shall I write one?
    I recon so.

    Yes, please do :)

    There are tests for what the _fix_env stuff is doing for IIS already
    here:

    http://dev.catalyst.perl.org/repos/Catalyst/Catalyst-Runtime/5.80/trunk/t/aggregate/unit_core_engine_fixenv-iis6.t

    More tests like this (failing) would be a great start, and there
    really should be some tests like this:

    http://dev.catalyst.perl.org/repos/Catalyst/Catalyst-Runtime/5.80/trunk/t/aggregate/unit_core_engine_cgi-prepare_path.t

    for these FastCGI cases also (as that would test that Catalyst is
    doing the right thing all the way through, not just that the mangling
    was working.

    If you fancy starting by grabbing the environment you're getting and
    writing failing test cases that'd be _brilliant_ :_)

    Feel free to mail them to the list, or come pester someone in
    #catalyst-dev for a commit bit so you can add them directly yourself.

    Thanks in advance.
    t0m

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedDec 18, '09 at 5:28p
activeDec 18, '09 at 7:06p
posts2
users2
websitecatalystframework.org
irc#catalyst

2 users in discussion

Tomas Doran: 1 post Stuart Watt: 1 post

People

Translate

site design / logo © 2021 Grokbase