Linux goesZen

wrong vhost Dancer deployment

Recently I've noticed on a small website running Dancer that my mode of deployment had a hard-to-find error. "Hard to find" as the website was behaving correctly - by accident - while the Apache configuration wasn't working as it should.

I found this specific bug in my setup by noticing that byte range requests were not answered with a byte range, although the client was asking for static content not handled by the dancer application.

While the Dancer docs recommend a different style of deploying an app via Apache (probably a more sane one), I usually use this config:

<VirtualHost>
.
.
.
## set everything for a Dancer site
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l

RewriteRule ^(.*)$ /dispatch.fcgi$1 [QSA,L]
</VirtualHost>

As you can see, I'm sending everything that's not a file within the app dir, or a directory, or a symlink - to the app's dispatch script. I copied this vhost rules from somewhere during the early days of Dancer and used it ever since as it "just worked" - until today.

When I found that byte ranges seemed to be served by the application I added a debug log output to the rewrite rules to see what was going on:

RewriteLog /var/www/site/logs/rewrite.log
RewriteLogLevel 3

a really handy directive as debugging mod_rewrite rules can be really painful. The output I got was:

00.00.00.00 - - [01/Mar/2017:13:40:26 +0000] [example.com.com/sid#7f8a4cad41aa][rid#7f8a4d336ae0/initial] (2) init rewrite engine with requested uri /res/style.css
00.00.00.00 - - [01/Mar/2017:13:40:26 +0000] [example.com.com/sid#7f8a4cad41aa][rid#7f8a4d336ae0/initial] (3) applying pattern '^(.*)$' to uri '/res/style.css'
00.00.00.00 - - [01/Mar/2017:13:40:26 +0000] [example.com.com/sid#7f8a4cad41aa][rid#7f8a4d336ae0/initial] (2) rewrite '/res/style.css' -> '/dispatch.fcgi/res/style.css'
00.00.00.00 - - [01/Mar/2017:13:40:26 +0000] [example.com.com/sid#7f8a4cad41aa][rid#7f8a4d336ae0/initial] (2) local path result: /dispatch.fcgi/res/style.css
00.00.00.00 - - [01/Mar/2017:13:40:26 +0000] [example.com.com/sid#7f8a4cad41aa][rid#7f8a4d336ae0/initial] (2) prefixed with document_root to /var/www/site/public/dispatch.fcgi/res/style.css
00.00.00.00 - - [01/Mar/2017:13:40:26 +0000] [example.com.com/sid#7f8a4cad41aa][rid#7f8a4d336ae0/initial] (1) go-ahead with /var/www/site/public/dispatch.fcgi/res/style.css [OK]
00.00.00.00 - - [01/Mar/2017:13:40:26 +0000] [example.com.com/sid#7f8a4cad41aa][rid#7f8a4d188d50/subreq] (2) init rewrite engine with requested uri /res/style.css
00.00.00.00 - - [01/Mar/2017:13:40:26 +0000] [example.com.com/sid#7f8a4cad41aa][rid#7f8a4d188d50/subreq] (3) applying pattern '^(.*)$' to uri '/res/style.css'
00.00.00.00 - - [01/Mar/2017:13:40:26 +0000] [example.com.com/sid#7f8a4cad41aa][rid#7f8a4d188d50/subreq] (2) rewrite '/res/style.css' -> '/dispatch.fcgi/res/style.css'
00.00.00.00 - - [01/Mar/2017:13:40:26 +0000] [example.com.com/sid#7f8a4cad41aa][rid#7f8a4d188d50/subreq] (2) local path result: /dispatch.fcgi/res/style.css
00.00.00.00 - - [01/Mar/2017:13:40:26 +0000] [example.com.com/sid#7f8a4cad41aa][rid#7f8a4d188d50/subreq] (2) prefixed with document_root to /var/www/site/public/dispatch.fcgi/res/style.css
00.00.00.00 - - [01/Mar/2017:13:40:26 +0000] [example.com.com/sid#7f8a4cad41aa][rid#7f8a4d188d50/subreq] (1) go-ahead with /var/www/site/public/dispatch.fcgi/res/style.css [OK]

As you can see, the static content was served by dispatch.fcgi - not right.
My assumption was that the probing of the local file-system wasn't working. That variable %{REQUEST_FILENAME} was not populated with the right path to match against the app's static directory tree.

Turned out, this is a common problem, as can be read here and here. So doing as user hlcs notes there "Adding %{DOCUMENT_ROOT} solved problem." for me as well.

Actually, I ran into the very same problem as Amandine here. Read it if you want a more verbose explanation of the problem.

After expanding the path properly via adding the document_root variable, the vhost rule for apache worked:

## set everything for a Dancer site
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-l

and I could confirm it by reading the rewrite log:

00.00.00.00 - - [01/Mar/2017:14:24:56 +0000] [www.example.com/sid#7fd64492b4e8][rid#7fd44002bab0/initial] (1) pass through /image.png
00.00.00.00 - - [01/Mar/2017:14:24:57 +0000] [www.example.com/sid#7fd64492b4e8][rid#7fd690044e20/initial] (2) init rewrite engine with requested uri /image2.png

A request here for image file image.png was recognized as being a real static file on file-system and "passed through" by apache - instead of sending it to the dispatch script. After that the app behaved just like before, only with increased performance on static files and proper handling of HTTP Range requests - as they were now handled by Apache directly.