[Dancer-users] Deployment question

[Robert Olson]

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_Apache_under_appdir
>
> 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
>