I respond to myself to clarify some things...
I patched the C::A::Dispatch handler function to print the $path_info variable (got with $r->path_info()) to a file in /tmp. Apparently for the URL localhost/lunae/home/mode3, $path_info is set to '/mode3' instead of '/home/mode3'. So the handler tries to load the module Lunae::Iface::Mode3 instead of Lunae::Iface::Home with run_mode set to 'mode3', and it fails and return a 404 not found message. I don't know why...
I recently found an issue with PATH_INFO where it behaved very strangely when some words where used in the location. For instance, with a <Location> of '/foo' a URL of '/foo/some_path/mode1' will give a PATH_INFO of '/some_path/mode1'. But a <Location> of '/include' and a URL of '/include/some_path/mode1' gives a PATH_INFO of '/mode1'. It seemed that everytime I chose a word that was an apache module (include, ssi, perl, alias, etc) it messed up my PATH_INFO.
I didn't have the time to track it down and create a proper bug report. This may (or may not) be related to what you are seeing. I wonder if you changed the name of 'home' to something else if it might work.
Another thing you might look at is to see if you have any other locations that start off with '/lunae' since this might also influence the PATH_INFO even if it doesn't process the response.
Just some ideas. Maybe there's something better than PATH_INFO that Dispatch can use. Any ideas?
-- Michael Peters Developer Plus Three, LP
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
