when to use which mod_rewrite rule for self routing? - mod-rewrite

Question

There are several ways to write a mod_write rule for self routing. At the moment i am using this one:
RewriteCond %{REQUEST_URI} !\.(js|ico|gif|jpg|png|css)$
RewriteRule ^.*$ index.php [NC,L]
But i also could use
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php
OR
ErrorDocument 404 /index.php
There may be many more.
Are there any drawbacks for using one of these examples?
Are there any use cases where one rule makes more sense then the other?
Could you explain the difference between these rules in detail?
Thx for your time and help.

Answer 1

When your condition is:
RewriteCond %{REQUEST_URI} !\.(js|ico|gif|jpg|png|css)$
Then only images, icons, styles, and javascript are excluded from routing. This means you can't access static html, directories, or directory indexes. So if you just want to plop down a static html page somewhere, and serve it without it getting routed through index.php. It also means if you accidentally put an image or script or style in the wrong place, and try to access it (you would normally get a 404), it wouldn't get routed through index.php eventhough and would yield the default 404 error page.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
These conditions will exclude any URI that points to an existing resource. So if you plot an image, a script, or directory, static html, etc anywhere in your document root, you'll be able to go there without it being routed through index.php. Sometimes the condition RewriteCond %{REQUEST_FILENAME} !-s is also included, which excludes URI's that point to a symlink. This is usually what you'd see when doing routing, wordpress uses this.
ErrorDocument 404 /index.php
This does essentially the same thing as the previous conditions, except it does it outside of mod_rewrite and there's no way to impose additional conditions in the future or as needed. The downside of doing routing outside of mod_rewrite is that mod_rewrite and the core directives (ErrorDocument in this case) do processing on the URI at different times in the URI-file mapping pipeline. So if you have rules that do other things, they could get applied, and then ultimately still get routed through index.php because the 2 directives are conflicting with each other. Simply because rewrite rules are applied at one point in the pipeline doesn't mean other directives won't get applied later down in the pipeline. This is a bad way to do routing.
There's also stuff like:
RewriteCond %{REQUEST_URI} !^/index.php
RewriteRule ^.*$ index.php [L]
Which will blindly route everything. Even javascript, even images, even static html, everything. Sometimes this is what people want. Ultimately, this is going to be dependent on what you want and what your index.php script does. Is it going to handle 404's? (like what you'd want in the first routing rule), is it just going to handle non-static resources? (like what the second rule does), or is it a literal catch all and will do everything (what the rule above does)?
Also note that your rewrite flags are different between the first and second rules. Those are significant if you have other rules.

Answer 2

The biggest drawback to the first example (which is the one you say that you use) is that this method hard codes the files extensions (.js .ico .gif .pnd) that are excluded from being rewritten to index.php. The problem with this is that if you need to add new static content that uses a file extension that is not in your exclusion list, you must modify your rewrite rule accordingly. For example, if you were to start hosting flash content and needed to host .swf and .flv files you will need to update your existing rewritecond rule.
The middle solution is best (IMHO) because it does exactly what is says it does, namely if the requested file doesn't exist (!-f condition) OR the requested directory doesn't exist (!-d condition) then rewrite the request to index.php.