jalmenarez / minify

Automatically exported from code.google.com/p/minify
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Option for non-expiring client cache #21

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
This would be the opposite of the current must-revalidate model, and where 
usable, would eliminate a ton of needless HTTP requests.

In the HTML you append a build number to your minify URLs.

1. Minify responds with content, but also far-off Expires/max-age headers 
and headers to let all proxies know they can cache the URL for practically 
"forever".
2. Due to this, the browser uses cache and doesn't even request the file 
on later page requests.
3. When you change any of the combined files, you (or some automated 
mechanism) updates the build # in the minify URLs on the site.
4. The browser sees these as new files and requests them.
5. Go to 1.

If a browser requests an older build (say from a search engine cache 
page), you can send the current output, or a 404.

Original issue reported on code.google.com by stephen....@gmail.com on 21 Sep 2007 at 4:44

GoogleCodeExporter commented 9 years ago
SVN version now has an option 'cacheUntil' for setting the Expires header 
(instead of
conditional GET). What's still needed is the mechanism for watching files and
maintaining the build #. This is probably outside the scope of Minify, but we 
should
publish a utility class to do it.

Original comment by mrclay....@gmail.com on 29 Feb 2008 at 2:26

GoogleCodeExporter commented 9 years ago
Minify_Build now creates "versioned" URLs, so one may safely set a far-off 
Expires
header via Minify's "setExpires" option. See Minify_Build comment.

Original comment by mrclay....@gmail.com on 14 May 2008 at 4:44