wdhawes at gmail
Jun 30, 2009, 6:51 AM
Post #4 of 5
(557 views)
Permalink
|
|
Re: Incorrect $c->req->base using Catalyst::Engine::SCGI on Win32
[In reply to]
|
|
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 :)
_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
|
