[Catalyst] Re: Incorrect $c->req->base using Catalyst::Engine::SCGI on Win32

[Will Hawes]

2009/6/28 Orlando Vazquez <ovazquez at gmail.com>:

> Ok, just to make sure I understand the root cause of this problem:
> Apache2.0 at Win32 sets SCRIPT_NAME to "/action" (or whatever PATH_INFO
> is), when it should really be something like "", "/" or undef, is this
> correct? I assume this only happens when the application is mounted
> under "/", and it does do the right this when mounted under say,
> something like "/myapp"?

That's correct, the problem only happens when mounted at "/" - things
behave as expected when mounted elsewhere.

> I'm the one who was responsible for removing the prepare_path method
> from the SCGI engine. I did this because it was overriding with an
> outdated verbatim copy of the prepare_path method in C::E::CGI, which
> ::SCGI inherits from.  Hmmm, ::FastCGI seems to include its own
> additional path fixes :\ Does it make sense to unify these tweaks in
> one place?

Almost certainly, although if you are in agreement I'd settle for
getting it working within C::E::SCGI in the first instance and
worrying about that later when I have some more time ;)

> Do you know if this problem manifests itself under the same webserver
> but different Catalyst engine?

Without having tested extensively, I think it's SCGI specific - I
don't see the problem with the CGI engine, at least.

> I appreciate the suggested fix but I don't think it's quite safe, as
> it would break something like /tags/tags where your app is mounted
> under "/tags" and you're calling the "/tags" action (you know, for
> whatever reason).
>
> But at the end of the day we have to get this to
> work well for you, so I'm not thrilled about but also not opposed to
> escaping this behaviour for this particular webserver since I know
> there's a few different servers that get it wrong.
>
> Could you check out how C::E::FastCGI::_fix_env for how to escape this
> for your particular webserver platform + version, and patch/commit a
> unittest+fix? I don't have a windows machine handy to test this
> appropriately, but you could probably fix this in a couple of minutes.

Good point, I'd not thought of the /tags/tags scenario.

Having played around with this a little more it looks as though when
things are working properly, REQUEST_URI is the same as SCRIPT_NAME
concatenated with PATH_INFO. With that in mind, perhaps revising the
suggested fix to something like this:

sub prepare_path { # or _fix_env?
    my( $self, $c ) = @_;
    my $env = $self->env;
    my $path_info = $env->{PATH_INFO} || '';
    my $script_name = $env->{SCRIPT_NAME} || '';
    my $request_uri = $env->{REQUEST_URI} || '';
    unless( $request_uri eq $script_name . $path_info ) {
        delete $env->{SCRIPT_NAME};
    }
    return $self->next::method( $c );
}

To be absolutely safe we could limit it to just this OS/web server as
you suggest:

    if( $^O eq 'MSWin32' && $env->{SERVER_SOFTWARE} =~ m{^Apache/2\.0\.63} ) {
        ...
    }

Let me know your thoughts on the above and I'll get to work on it.

> P.S.
>
> I got your doc bug report - it's been fixed and pushed up to the
> Catalyst git repo :)

Thanks :)