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