Sorry for the slow reply - been busy, and haven't had time to give it the attention it deserves. Firstly, multi-app support is going to be a *lot* better and cleaner in Dancer2, so I doubt we want to do any really major overhauling of Dancer for this, we'd be better off just getting Dancer2 ready for primetime :) Having said that, though, it seems you might have spotted something: On Sunday 20 November 2011 14:40:43 Perlover wrote:
Good day!
I found a buggy behavior of Dancer with multiply application configuration and routes. [...] .... sub find_route_through_apps { my ($class, $request) = @_; for my $app (Dancer::App->current, Dancer::App->applications) { my $route = $app->find_route($request); ....
Here we see that searching is going until the target route will be found in all applications! Imagine that we requested the url /app1/admin/... What happens? The $app1 will get path_info as /admin/... after Plack::App::URLMap and Dancer will start a searching in find_route_through_apps and will find a route of $app2! And it will call it code without middleware Auth! And protected and security data will be given for remote user without protection!
What is result? The /app1/ URLs will sometimes run app2's routes, the /app2/ URLs will sometimes run a routes of app1 and so on. [...]
At a quick glance, it sounds like you might have found the source of the issue some people have seen using multiple apps via Apache2 / Plack, where requests sometimes hit the wrong app. I'm not entirely sure, though. [...]
What i suggest ?
I think Dancer should have:
1) For get & post now we can pass an options hashref before code like this get '/' => {option1 =>..., ...}, sub {} (i see this in code of Dancer but i didn't find it in docs) . I think there should be option 'route_namespace' for example. If it defined it consists a namespace of this route. If not defined it has a namespace defined in route_namespace command (point 2 here)
2) Should be command like 'prefix' but named as 'route_namespace' fro setting up namespace of routes of this application. The prefix option for real pieces in $request->path_info but this route_namespace for virtual because we cannot get a namespace from path_info (only from $request->script_name but i want to make this behavior flexible for 'route_namespace')
I'm not entirely sure this is required; I think the main fix, if it is required, is to make sure that the code that looks for matching routes can only ever consider routes within the app which is executing, if that's where the problem is. Personally, I'm not all that familiar with setting up multiple appps via Plack::Builder stuff - in my usage, I've always just started up apps separately via Starman, giving great performance and isolation, and letting me tweak the number of worker processes per-app appropriately, etc, then stick Nginx in front as a caching proxy (and ready to be replaced with a load balancer if the load grows enough to require sharing across boxes). Anyone else have any thoughts on this?