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

[Orlando Vazquez]

Hi Will, apologizes for the delayed response;

> From a combination of the debug screen in the browser and the server
> output, I can see the following under Apache 2.0 on Win32 (observed on
> 2 machines):
>
> PATH_INFO - /action
> SCRIPT_NAME - /action
> $c->req->base - http://localhost/action/
> $c->uri_for( $c->action ) - http://localhost/action/action
>
> I don't think the SCRIPT_NAME header should contain anything. Under
> Apache 2.2 on Ubuntu 9.04, I see the behaviour I expected:
>
> PATH_INFO - /action
> SCRIPT_NAME - (not present)
> $c->req->base - http://localhost/
> $c->uri_for( $c->action ) - http://localhost/action
>

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"?

> The old Catalyst::Engine::SCGI code addressed this kind of issue in
> its prepare_path method. Not sure if that's still the recommended way
> (that method has been removed from the CPAN release), but perhaps
> something like the following would be sufficient (untested):
>
> sub prepare_path {
>     my( $self, $c ) = @_;
>     my $env = $self->env;
>     if( $env->{PATH_INFO} && $env->{SCRIPT_NAME} && $env->{PATH_INFO}
>     eq $env->{SCRIPT_NAME} ) {
>         delete $env->{SCRIPT_NAME};
>     }
>     return $self->next::method( $c );
> }

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?

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

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.

P.S.

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

Many thanks, :)

Orlando Vazquez