I'm starting to try to use Dancer in some apps at my day job; here, we have a bunch of apps that we have hung off an nginx proxy server (some using fcgi, some straight reverse proxy). What distinguishes this that we don't use vhosts for all of them; instead, we distinguish based on a toplevel directory. For instance / foo would be delivered to one machine's fcgi , /bar to some other machine's apache. I'd like to be able to use this mechanism to proxy off to a Dancer standalone server. However, to the instance locally it things stuff is rooted at /, but to the clients it's rooted at /somethingelse. I have tinkered with the prefix directive, which makes the actions work ok, but breaks the stuff under public. And if I generate urls inside the actions (like /something/postme), they are incorrect when used in the proxied context. (I'm not sure if this is an entirely cogent explanation; if not let me know and I'll take another run at it with a concrete example :-). --bob
Hi Bob, Le jeudi 01 avril 2010 à 16:15 -0500, Robert Olson a écrit : [...]
What distinguishes this that we don't use vhosts for all of them; instead, we distinguish based on a toplevel directory. For instance / foo would be delivered to one machine's fcgi , /bar to some other machine's apache.
I'd like to be able to use this mechanism to proxy off to a Dancer standalone server. However, to the instance locally it things stuff is rooted at /, but to the clients it's rooted at /somethingelse.
OK, this is something possible.
I have tinkered with the prefix directive, which makes the actions work ok, but breaks the stuff under public.
Well, the "prefix" keyword should not be used for deployment configuration, it's only provided to help defining multiple routes in the same "namespace". We already documented the situation you describe for Apache2 in the deployment guide: http://search.cpan.org/dist/Dancer/lib/Dancer/Deployment.pod#Running_from_Ap... Look at the rewrite rules in that example. I don't know if that's similar to what you can do with nginx, but my bet is that if we can do it under Apache2, there's no reason we can't under nginx. Maybe you can paste here some of your relevant configuration files, so we can investigate together. Regards, -- Alexis Sukrieh
I'm taking another run at this in a different context (setting up a Dancer app in my dreamhost.com shared account). Here, I need to use .htaccess files, and I'm setting the app up in a subdir of my domain's document root. This is the .htaccess I have: AddHandler fastcgi-script .fcgi Options +FollowSymLinks +ExecCGI RewriteEngine On RewriteCond %{REQUEST_FILENAME} !dispatch.fcgi RewriteRule ^(.*)$ public/dispatch.fcgi/$1 [QSA,L] This works fine to get the web pages themselves (though the route '/' really is '/wellness2010' because of my installation into the subdirectory. The problem is with the generated paths for the css in the default layout, which uses /css that doesn't exist (but / wellness2010/css does). I can change the link in teh layout to be the full path, but that still leaves the discrepancy in the route definitions. Note also there's an anomaly in how per-directory rewrites work; you don't have access to the directory name as apache strips it before doing the match, then restores it afterwards. Here is a detailed rewrite log for a similar .htaccess setup on my home system (as I can't turn up rewrite debugging at dreamhost). Application directory is "x1": (2) init rewrite engine with requested uri /foo/bar (1) pass through /foo/bar (2) init rewrite engine with requested uri /x1/foo/bar (1) pass through /x1/foo/bar (3) [perdir /srv/www/htdocs/x1/] add path info postfix: /srv/www/ htdocs/x1/foo -> /srv/www/htdocs/x1/foo/bar (3) [perdir /srv/www/htdocs/x1/] strip per-dir prefix: /srv/www/ htdocs/x1/foo/bar -> foo/bar (3) [perdir /srv/www/htdocs/x1/] applying pattern '^(.*)$' to uri 'foo/bar' (4) [perdir /srv/www/htdocs/x1/] RewriteCond: input='/srv/www/htdocs/ x1/foo' pattern='!dispatch' => matched (2) [perdir /srv/www/htdocs/x1/] rewrite 'foo/bar' -> 'public/ dispatch.cgi/foo/bar' (3) [perdir /srv/www/htdocs/x1/] add per-dir prefix: public/ dispatch.cgi/foo/bar -> /srv/www/htdocs/x1/public/dispatch.cgi/foo/bar (2) [perdir /srv/www/htdocs/x1/] strip document_root prefix: /srv/ www/htdocs/x1/public/dispatch.cgi/foo/bar -> /x1/public/dispatch.cgi/ foo/bar (1) [perdir /srv/www/htdocs/x1/] internal redirect with /x1/public/ dispatch.cgi/foo/bar [INTERNAL REDIRECT] Now process the internal redirect: redir#1] (2) init rewrite engine with requested uri /x1/public/ dispatch.cgi/foo/bar redir#1] (1) pass through /x1/public/dispatch.cgi/foo/bar redir#1] (3) [perdir /srv/www/htdocs/x1/] add path info postfix: /srv/ www/htdocs/x1/public/dispatch.cgi -> /srv/www/htdocs/x1/public/ dispatch.cgi/foo/bar redir#1] (3) [perdir /srv/www/htdocs/x1/] strip per-dir prefix: /srv/ www/htdocs/x1/public/dispatch.cgi/foo/bar -> public/dispatch.cgi/foo/bar redir#1] (3) [perdir /srv/www/htdocs/x1/] applying pattern '^(.*)$' to uri 'public/dispatch.cgi/foo/bar' redir#1] (4) [perdir /srv/www/htdocs/x1/] RewriteCond: input='/srv/www/ htdocs/x1/public/dispatch.cgi' pattern='!dispatch' => not-matched redir#1] (1) [perdir /srv/www/htdocs/x1/] pass through /srv/www/htdocs/ x1/public/dispatch.cgi (2) init rewrite engine with requested uri /foo/bar (1) pass through /foo/bar the environment we get includes PATH_INFO=/foo/bar PATH_TRANSLATED=/srv/www/htdocs/foo/bar PWD=/srv/www/htdocs/x1/public QUERY_STRING= REDIRECT_SCRIPT_URI=http://barney/x1/foo/bar REDIRECT_SCRIPT_URL=/x1/foo/bar REDIRECT_STATUS=200 REDIRECT_URL=/x1/foo/bar REQUEST_METHOD=GET REQUEST_URI=/x1/foo/bar SCRIPT_FILENAME=/srv/www/htdocs/x1/public/dispatch.cgi SCRIPT_NAME=/x1/public/dispatch.cgi SCRIPT_URI=http://barney/x1/foo/bar PATH_TRANSLATED lost the /x1, interestingly. I guess one solution would be for me to explicitly configure my app to be told where it is in the URI space, and use that information to construct the appropriate css refs, etc in the templates. It would have to be done for any URL that is created that is visible outside the app (form POST addresses, any absolute urls, etc). But it can't show up in the routes, because of the rewrite Dancer thinks it's rooted at /. --bob On Apr 2, 2010, at 1:25 AM, Alexis Sukrieh wrote:
Hi Bob,
Le jeudi 01 avril 2010 à 16:15 -0500, Robert Olson a écrit : [...]
What distinguishes this that we don't use vhosts for all of them; instead, we distinguish based on a toplevel directory. For instance / foo would be delivered to one machine's fcgi , /bar to some other machine's apache.
I'd like to be able to use this mechanism to proxy off to a Dancer standalone server. However, to the instance locally it things stuff is rooted at /, but to the clients it's rooted at /somethingelse.
OK, this is something possible.
I have tinkered with the prefix directive, which makes the actions work ok, but breaks the stuff under public.
Well, the "prefix" keyword should not be used for deployment configuration, it's only provided to help defining multiple routes in the same "namespace".
We already documented the situation you describe for Apache2 in the deployment guide: http://search.cpan.org/dist/Dancer/lib/Dancer/Deployment.pod#Running_from_Ap...
Look at the rewrite rules in that example. I don't know if that's similar to what you can do with nginx, but my bet is that if we can do it under Apache2, there's no reason we can't under nginx.
Maybe you can paste here some of your relevant configuration files, so we can investigate together.
Regards,
-- Alexis Sukrieh
Hi,
I guess one solution would be for me to explicitly configure my app to be told where it is in the URI space, and use that information to construct the appropriate css refs, etc in the templates. It would have to be done for any URL that is created that is visible outside the app (form POST addresses, any absolute urls, etc).
This makes sense, I suppose a template helper like 'url_for($path)' would be appropriate. This could be easily done with a setting like 'application_root'. Then we could have : use Dancer; set application_root => '/myappdir'; get '/' => sub { # the home route }; # in templates ... <link rel="text/css" src="<% url_for('/css/style.css) %>" /> Tell me if this feature looks to solve your issue. If this is the case, feel free to open a ticket on GitHub <http://github.com/sukria/Dancer/issues> Regards, -- Alexis Sukrieh
participants (2)
-
Alexis Sukrieh -
Robert Olson