Question

I have an application that routes all requests through index.php.

Here’s my setup:

1. I access the application at http://www.example.com/sample/
2. On the filesystem, the application sits in /home/chris/www/sample/
3. The web-accessible directory of the application lives at /home/chris/www/sample/app/web.
4. The DocumentRoot is set to /home/chris/www

/home/chris/www/sample/.htaccess is configured as follows:

RewriteEngine on

RewriteCond   %{REQUEST_URI}    ^/sample/(.+)$
RewriteCond   %{DOCUMENT_ROOT}/sample/app/web/%1  -f
RewriteRule   ^/sample/(.*)$    %{DOCUMENT_ROOT}/sample/app/web/%1 [L]

RewriteRule   ^(.+)$            index.php?ws_page=$1 [L,NC,QSA]

I’ve tried multiple configurations, but haven’t figured out why I keep getting 404’s on calls to “real” files.

Sample 404:

`http://www.example.com/sample/_css/960/reset.css`

(which I want to have rewritten to /home/chris/www/sample/app/web/_css/960/reset.css)

EDIT

I have already tried

RewriteCond %{REQUEST_URI} !-f
RewriteCond %{REQUEST_URI} !-d
RewriteCond %{REQUEST_URI} !-l

and they did not work, because the %{REQUEST_URI} prefix does not match the filesystem prefix of these files.

EDIT 2

To clarify, I want requests of the form

`http://www.example.com/sample/foo/bar`

to be rewritten to the filesystem object /home/chris/www/sample/app/web/foo/bar, but only if that filesystem object exists.

Answer 1

One of the biggest bear-pits in reading the mod_rewrite documentation in the difference in behaviour in a system (that this the main and vhost configs that apache reads on start-up and those directive processes in a per-directory context. See the Per-directory Rewrites subsection of the RewriteRule documentation for further details.

When using the rewrite engine in .htaccess files the per-directory prefix (which always is the same for a specific directory) is automatically removed for the RewriteRule pattern matching and automatically added after any relative (not starting with a slash or protocol name) substitution encounters the end of a rule set. See the RewriteBase directive for more information regarding what prefix will be added back to relative substitions.

and later

The removed prefix always ends with a slash, meaning the matching occurs against a string which never has a leading slash. Therefore, a Pattern with ^/ never matches in per-directory context. What you’ve done is to code around this.

Incidentally, this is why it is always safer to specify a RewriteBase, as the engine gets this wrong without this.

BTW, this second quote can be wrong because the prefix add-back occurs at the then of the rule set execution, and if you have a successful rule which is to a different relative branch (that is the target starts with a /) but without the [L] flag set, then the engine falls through to any subsequent rules with a leading / set. Most confusing, so my general advice is never rely on fall-through rules. Always force an immediate internal or external redirect on a successful substitution in a per-directory context as the engine has this and a couple of other bugs in this fall-through processing.