Comments on: Fake Filenames for Far Future Expires Headers https://www.barneyb.com/barneyblog/2010/03/10/fake-filenames-for-far-future-expires-headers/ Thoughts, rants, and even some code from the mind of Barney Boisvert. Thu, 11 Sep 2014 09:58:12 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Andy https://www.barneyb.com/barneyblog/2010/03/10/fake-filenames-for-far-future-expires-headers/comment-page-1/#comment-225025 Andy Wed, 03 Nov 2010 18:32:23 +0000 http://www.barneyb.com/barneyblog/?p=1362#comment-225025 Has anyone come across the following problem I have searched high and low and not found anything about this.... the + in the file name seems to thwart the far futures expires http://www.ineaguide.org/files/imagecache/100X100/villa+eugenie.jpg Has anyone come across the following problem

I have searched high and low and not found anything about this….

the + in the file name seems to thwart the far futures expires

http://www.ineaguide.org/files/imagecache/100X100/villa+eugenie.jpg

]]> By: Ben Nadel https://www.barneyb.com/barneyblog/2010/03/10/fake-filenames-for-far-future-expires-headers/comment-page-1/#comment-207662 Ben Nadel Fri, 12 Mar 2010 21:52:36 +0000 http://www.barneyb.com/barneyblog/?p=1362#comment-207662 I can totally understand that. A lot of what I do in my code is based purely on aesthetics (I am not joking). I can totally understand that. A lot of what I do in my code is based purely on aesthetics (I am not joking).

]]> By: barneyb https://www.barneyb.com/barneyblog/2010/03/10/fake-filenames-for-far-future-expires-headers/comment-page-1/#comment-207661 barneyb Fri, 12 Mar 2010 21:49:59 +0000 http://www.barneyb.com/barneyblog/?p=1362#comment-207661 Yep, I used to do the same thing (see http://www.barneyb.com/barneyblog/2009/01/07/getsubversionrevision-udf/), and while it seemed to work correctly, I was never very happy with the gnarly-looking URLs. Having the number in the filename appeals far more to my sense of aesthetics, as well as appearing to use normal web best practices. Yep, I used to do the same thing (see http://www.barneyb.com/barneyblog/2009/01/07/getsubversionrevision-udf/), and while it seemed to work correctly, I was never very happy with the gnarly-looking URLs. Having the number in the filename appeals far more to my sense of aesthetics, as well as appearing to use normal web best practices.

]]> By: Ben Nadel https://www.barneyb.com/barneyblog/2010/03/10/fake-filenames-for-far-future-expires-headers/comment-page-1/#comment-207660 Ben Nadel Fri, 12 Mar 2010 21:43:00 +0000 http://www.barneyb.com/barneyblog/?p=1362#comment-207660 One approach that I have used in the past, which is quite similar, is to have the "script version" as a query param rather than as the file name: /path/to/script.js?v=#application.scriptVersion# I am not 100% sure if this will cache the same same way as a file name, though. As far as the header values, I've only ever played with the expires - I have no idea how to mess with ETags on IIS :) One approach that I have used in the past, which is quite similar, is to have the "script version" as a query param rather than as the file name:

/path/to/script.js?v=#application.scriptVersion#

I am not 100% sure if this will cache the same same way as a file name, though. As far as the header values, I've only ever played with the expires – I have no idea how to mess with ETags on IIS :)

]]> By: barneyb https://www.barneyb.com/barneyblog/2010/03/10/fake-filenames-for-far-future-expires-headers/comment-page-1/#comment-207589 barneyb Thu, 11 Mar 2010 17:50:20 +0000 http://www.barneyb.com/barneyblog/?p=1362#comment-207589 Chris, Yeah, you're right. I simplified the rules from what I actually use, and screwed it up. All fixed now though. Using Ant to set the variable from SVN is a cinch, though it'll increment too often if you just check "last revision". You don't want to be updating the variable every time a non-asset changes or you'll needlessly be churning cache and reduce the effectiveness. But you could certainly constrain the check to only the asset files, and increment only when those change. I used a similar approach on a site a while back where the production site was actually a working copy (not ideal, but there were legit reasons), so I could just inspect the SVN metadata of the working copy itself to get the number. That worked pretty well too. Chris,

Yeah, you're right. I simplified the rules from what I actually use, and screwed it up. All fixed now though.

Using Ant to set the variable from SVN is a cinch, though it'll increment too often if you just check "last revision". You don't want to be updating the variable every time a non-asset changes or you'll needlessly be churning cache and reduce the effectiveness. But you could certainly constrain the check to only the asset files, and increment only when those change.

I used a similar approach on a site a while back where the production site was actually a working copy (not ideal, but there were legit reasons), so I could just inspect the SVN metadata of the working copy itself to get the number. That worked pretty well too.

]]> By: Chris Blackwell https://www.barneyb.com/barneyblog/2010/03/10/fake-filenames-for-far-future-expires-headers/comment-page-1/#comment-207561 Chris Blackwell Thu, 11 Mar 2010 09:25:27 +0000 http://www.barneyb.com/barneyblog/?p=1362#comment-207561 The rewrite rule isn't quite right, there's no second group to be referenced as $2 Should be RewriteRule (.*)_[0-9]+\.js$ $1.js What would be really cool is if you had your ant build script set the variable application.scriptVersion with your revision from SVN The rewrite rule isn't quite right, there's no second group to be referenced as $2
Should be

RewriteRule (.*)_[0-9]+\.js$ $1.js

What would be really cool is if you had your ant build script set the variable application.scriptVersion with your revision from SVN

]]>