On Apr 3, 2008, at 7:46 PM, Michael S. Fischer wrote: > On Thu, Apr 3, 2008 at 7:37 PM, Ricardo Newbery <[EMAIL PROTECTED] > > wrote: > >> URL versioning is usually not appropriate for html >> pages or other primary resources that are intended to be reached >> directly by >> the end user and whose URLs must not change. > > Back to square one. Are these latter resources dynamic, or are they > static? > > - If they are dynamic, neither your own proxies nor upstream proxies > should be caching the content. > - If they are static, then they should be cacheable for the same > amount of time all the way upstream (modulo protected URLs). > > I've haven't yet seen a defensible need for varying cache lifetimes, > depending on the proximity of the proxy to the origin server, as this > request seems to be. Of course, I'm open to being convinced otherwise > :-)
Well, first of all you're setting up a false dichotomy. Not everything fits neatly into your apparent definitions of dynamic versus static. Your definitions appear to exclude the use case where you have cacheable content that is subject to change at unpredictable intervals but which is otherwise fairly "static" for some length of time. Sometimes, in such a case, serving stale content for some time after an edit is an acceptable compromise between performance and freshness but often it is not. And sometimes, impacting overall performance by hitting the backend for every such request is also undesirable. Thankfully, those are not the only choices. With a combination of PURGE requests and something like Surrogate-Control (or hardcoded behavior in your reverse-proxy config), you can still insure immediate freshness (or whatever level of freshness you require) without forcing your backend to do all the work. Ric _______________________________________________ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc