# this does cache related stuff
<Location ~ "^/path/to/assets/.*\.(js|css|png)$">
    ExpiresActive   On
    ExpiresByType   application/x-javascript    "now plus 1 month"
    ExpiresByType   text/css                    "now plus 1 month"
    ExpiresByType   image/png                   "now plus 1 month"

    Header  set     Cache-Control       "public"
    Header  set     Pragma              ""
    Header  unset   Last-Modified
    Header  unset   ETag
    FileETag    None
</Location>

# this enabled deflating (gzipping) JS and CSS
<FilesMatch "\.(js|css)$">
    SetOutputFilter DEFLATE
</FilesMatch>

RewriteRule /

[redirect=permanent,cachelifetime="1 month"]

But it doesn`t work!!!!

I try to realize a script witch Rewrite to set the caching of images to an month and to compress the js-scripts. It is for a static html-page.

The problem is I have no idea how to manage that! Is it possible in a .htaccess?

Greeds & Thanks,
Matthias

I have no idea. As long as it has the "check for file existence" capabilities, I don't see why it wouldn't work, but I don't run IIS anywhere.

Bottom line, disk I/O is the least of your worries. Doing some filesystem checks is going to be WAY faster than spinning up an HttpRequest for CF to process, let alone the actual CF processing. If you've got dedicated servers for purely static assets, then the I/O will become a potential issue, but short of that it's quite unlikely. Any decent OS will cache in RAM as well, which will quite possible avoid even a disk seek.

WordPress MU, for example, uses that exact sort of global rewrite with existence check:

# if it's a real path, just serve it
RewriteCond  %{REQUEST_FILENAME}  -f  [OR]
RewriteCond  %{REQUEST_FILENAME}  -d
RewriteRule  .                    -   [L]
# strip the blog slug and run wp- and .php resources
RewriteRule  ^([_0-9a-zA-Z-]+/)?(wp-.*)     $2  [L]
RewriteRule  ^([_0-9a-zA-Z-]+/)?(.*\.php)$  $2  [L]
# point everything else at index.php
RewriteRule  .  index.php  [L]

Dude, I apologize — my first comment is literally half the length of your post! Here's a quick follow up…

Along the lines of my prior comment — I'm assuming Apache is smart enough to stop testing chained RewriteCond if one fails (since adjacent RewriteCond lines are chained by implicit AND's), so in your example I think you could save those microseconds on the disk hit that I'm worried about ;-) You could add this first RewriteCond prior to what you show in the example… I think?

RewriteCond  %{REQUEST_URI}  ^/tn/p([0-9]+)-([0-9]+)x([0-9]+)\.jpg$
RewriteCond  %{REQUEST_FILENAME}  !-s
RewriteRule  ^/tn/p([0-9]+)-([0-9]+)x([0-9]+)\.jpg$  /gen_tn.cfm?id=$1&width=$2&height=$3  [PT,L]

In fact, I was working on some mod_rewrite stuff just this morning, which is slightly related. I was using the !-s in a RewriteCond for a slightly different purpose, but I became concerned that this could actually worsen performance in my case. I assume "RewriteCond %{REQUEST_FILENAME} !-s" must hit the file system every time, since it's checking for the existence of a file on disk and its size, so there must be some penalty there, right?

In your case, I'd imagine it's probably worthwhile, because that's certainly faster than regenerating an image every time, however, that condition check occurs on *every* other request (unless you can use other RewriteCond/RewriteRule logic to "short-circuit" when the !-s check is not required).

Here's my situation: I'm simply using a rewrite rule for a CMS so I can avoid /index.cfm/alias-stuff/here/ type URLs and rewrite something like /alias-stuff/here/ instead. However, there are other *.cfm URLs on the site that I do not want to rewrite. So, here was my first pass, which works great:

RewriteCond  %{DOCUMENT_ROOT}/%{REQUEST_FILENAME}  !-d
RewriteCond  %{DOCUMENT_ROOT}/%{REQUEST_FILENAME}  !-s
RewriteRule  ^(.*)$  /index.cfm%{REQUEST_URI}  [NE,QSA]

When I became paranoid about the disk hits, I changed it to the following, which has one RewriteCond that will be met as long as there is a period (.) in the REQUEST_URI (because my CMS-aliased URLs will never contain a period, but any URL with a file exension will):

RewriteCond  %{REQUEST_URI}  !^(.*\..+)
RewriteRule  ^(.*)$  /index.cfm%{REQUEST_URI}  [NE,QSA]

This seems to work great for my current situation, but isn't quite as universally reusable as the first option. My thinking is that the one condition with a regex evaluation will perform better than 2 disk hits, which would occur on every request, even the many requests for images, CSS, JS, etc. Am I way too paranoid, or does this make sense to you?

One other option I considered was a condition that ensured specific extensions were not in the URL, but it seemed unruly and more difficult to maintain:

RewriteCond  %{REQUEST_URI}  !^(.*\.(avi|bmp|cfc|cfm|cfml|cfr|css|csv|doc|gif|htm|html|jpg|js|mov|mp3|mpeg|php|pdf|png|ppt|swf|txt|xls))

Finally (sorry this is such a long-winded comment!)… You may have noticed that I used this:

RewriteCond  %{DOCUMENT_ROOT}/%{REQUEST_FILENAME}  !-s

…instead of this:

RewriteCond  %{REQUEST_FILENAME}  !-s

Everything I've read, including your example, suggests that %{REQUEST_FILENAME} would represent the full physical path, but I had to include "%{DOCUMENT_ROOT}/" in front to get it to work. Do you know of another Apache configuration that would cause this issue? FWIW, I'm doing all of my rewrite rules inside my vhosts, not .htaccess.

Thanks!