[Dancer-users] Dancer - new suggestion - "route namespace"

David Precious davidp at preshweb.co.uk
Wed Nov 23 11:18:51 CET 2011


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?



More information about the Dancer-users mailing list