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: apache...@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 _______________________________________________ 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/