This is great stuff! I’m terrible at regular expressions—my brain just doesn’t seem to want to remember any of it—but this article contains the clearest description of regular expressions I’ve come across.
I thought I’d share a useful little rewrite rule that I use for cache-busting JavaScript and CSS files. You know the story: you make a change in your JavaScript or CSS and you want to let the browser know that it should grab the new version instead of using what it’s got in its cache.
Now, I could potentially just use a query string when I point to my JS and CSS files ( e.g. /js/myscript.js?20131201 ) …but that can cause issues with proxy servers.
Instead what I what I do is point to files like this:
/js/myscript.20131201.js
Then I need to tell the server to look for the actual file in /js/myscript.js
Here’s the rewrite rule I’m using:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.).(d).(js|css)$ $1.$3 [L]
It’s basically telling the server that, if the JS or CSS file doesn’t actually exist and it matches the pattern of having two dots before the file extension (with only numbers after the first dot), to look at the bit before the first dot, and look at the bit after the second dot, but to ignore the bit in between (the numbers).
The server serves up the right file, but browsers fetch the new version because, as far as they’re concerned, this looks like a brand new file that they haven’t got in their cache.
That was a terrible explanation, wasn’t it? I now have even more appreciation for how clearly and concise this article is.
Jeremy Keith
This is great stuff! I’m terrible at regular expressions—my brain just doesn’t seem to want to remember any of it—but this article contains the clearest description of regular expressions I’ve come across.
I thought I’d share a useful little rewrite rule that I use for cache-busting JavaScript and CSS files. You know the story: you make a change in your JavaScript or CSS and you want to let the browser know that it should grab the new version instead of using what it’s got in its cache.
Now, I could potentially just use a query string when I point to my JS and CSS files ( e.g. /js/myscript.js?20131201 ) …but that can cause issues with proxy servers.
Instead what I what I do is point to files like this:
/js/myscript.20131201.js
Then I need to tell the server to look for the actual file in /js/myscript.js
Here’s the rewrite rule I’m using:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.).(d).(js|css)$ $1.$3 [L]
It’s basically telling the server that, if the JS or CSS file doesn’t actually exist and it matches the pattern of having two dots before the file extension (with only numbers after the first dot), to look at the bit before the first dot, and look at the bit after the second dot, but to ignore the bit in between (the numbers).
The server serves up the right file, but browsers fetch the new version because, as far as they’re concerned, this looks like a brand new file that they haven’t got in their cache.
That was a terrible explanation, wasn’t it? I now have even more appreciation for how clearly and concise this article is.