Skip Menu |

This queue is for tickets about the Catalyst-Engine-Apache CPAN distribution.

Report information
The Basics
Id: 26921
Status: resolved
Priority: 0/
Queue: Catalyst-Engine-Apache

People
Owner: Nobody in particular
Requestors: dotcomguy [...] triple-d.us
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

Attachments


Subject: Problem with path and <LocationMatch ^/$>
Date: Thu, 03 May 2007 13:46:35 -0400
To: bug-Catalyst-Engine-Apache [...] rt.cpan.org
From: "Denny D. Daugherty" <dotcomguy [...] triple-d.us>
I have been using Catalyst and LocationMatch in the Apache configuration to designate which portions of the site should be handled by Catalyst. In addition to explicit paths, I also have the following in my configuration for the home page of the sit: <LocationMatch ^/$> SetHandler perl-script PerlHandler Layover::Catalyst </LocationMatch> I then have an index method in Catalyst::Controller::Root to handle this request. However, since upgrading Catalyst::Engine::Apache I am now getting a 404 for that request. It seems Catalyst is using the path "^/$" and is going through the 'default' method of Root rather than index. This happened after upgrading to 1.09. Downgrading to 1.07 resolved the issue. perl is v5.8.8 2.6.19 #1 Fri Dec 8 14:11:58 EST 2006 i686 GNU/Linux Regards, -- Denny D. Daugherty
From: AGRUNDMA [...] cpan.org
What version of Apache and mod_perl are you running? I actually don't see how this would work back in 1.07, the problem is we use the $r->location method in mod_perl which returns the value of either a plain Location block or the LocationMatch regex.
I think I solved the problem, can you please try the attached module and see if it works for you?

Message body not shown because it is not plain text.

This bug is fixed in 1.10.
From: dotcomguy [...] triple-d.us
On Tue May 15 22:07:00 2007, AGRUNDMA wrote: Show quoted text
> This bug is fixed in 1.10.
There are still problems with LocationMatch in 1.10 and 1.11. It works fine for the <LocationMatch ^/$> however not for other uses of LocationMatch. Here is an example: <Location ^/(foo|bar|baz)(/|$)> SetHandler perl-script PerlHandler Layover::Catalyst </Location> In 1.11, this code works fine and is handled by Catalyst::Controller::Root as expected. However, say you have three other controllers: * Catalyst::Controller::Foo * Catalyst::Controller::Bar * Catalyst::Controller::Baz In 1.07 it will correctly dispatch to the correct controller, so if I visit http://www.example.com/foo/test it will refer to Catalyst::Controller::Foo->test. However, in 1.11 when visiting example.com/foo it displays the same as example.com/ (Catalyst::Controller::Root) and when visiting example.com/foo/test it falls back to Catalyst::Controller::Root as well.
On Fri Dec 14 13:39:43 2007, dotcomguy@triple-d.us wrote: Show quoted text
> On Tue May 15 22:07:00 2007, AGRUNDMA wrote:
> > This bug is fixed in 1.10.
> > There are still problems with LocationMatch in 1.10 and 1.11. It works > fine for the <LocationMatch ^/$> however not for other uses of > LocationMatch. Here is an example: > > <Location ^/(foo|bar|baz)(/|$)> > SetHandler perl-script > PerlHandler Layover::Catalyst > </Location> > > In 1.11, this code works fine and is handled by > Catalyst::Controller::Root as expected. However, say you have three > other controllers: > > * Catalyst::Controller::Foo > * Catalyst::Controller::Bar > * Catalyst::Controller::Baz > > In 1.07 it will correctly dispatch to the correct controller, so if I > visit http://www.example.com/foo/test it will refer to > Catalyst::Controller::Foo->test. > > However, in 1.11 when visiting example.com/foo it displays the same as > example.com/ (Catalyst::Controller::Root) and when visiting > example.com/foo/test it falls back to Catalyst::Controller::Root as well.
Just a few comments from me that might lead to close this bug as I also often think about this problem. The problem is IMHO not generally solveable. It has to do it either way. There are always regexes in LocationMatch that cannot be mapped to a unambiguously path. Now, since C::E::Apache 1.10 tries to cleverly map to the longest possible pathpart of the regex you can work around that problem by making your regex "non-trivial enough" so that the regex cannot be mapped to a path. See section "Application base" in catalyst calendar entry http://catalyst.perl.org/calendar/2007/17 for deliberate uses of that. My proposed patch in http://rt.cpan.org/Ticket/Display.html?id=32150 hides the resulting "uninitialized values" warnings that occur with such "non-trivial" regexes. I wouldn't change the current behaviour again but maybe additionally make it possible to deactivate the attempt to map from regex to a path, maybe with a dedicated apache directive or variable. See my symbolic patch for clarification. Regards, Steffen -- Steffen Schwigon <schwigon@webit.de> Dresden Perl Mongers <http://dresden-pm.org/> Deutscher Perl-Workshop <http://www.perl-workshop.de/>
--- Apache.pm.orig 2008-01-08 08:45:00.000000000 +0100 +++ Apache.pm.without_locationmatch_mapping 2008-01-08 09:27:00.000000000 +0100 @@ -133,7 +133,7 @@ # Check if $base_path appears to be a regex (contains invalid characters), # meaning we're in a LocationMatch block - if ( $base_path =~ m/[^$URI::uric]/o ) { + if ( $base_path =~ m/[^$URI::uric]/o AND NOT APACHEVARIABLE('CATALYST_DISABLE_LOCATIONMATCH_MAPPING') ) { # Find out what part of the URI path matches the LocationMatch regex, # that will become our base my $match = qr/($base_path)/;
In 1.12 you can now set PerlSetVar CatalystDisableLocationMatch 1