Re: dilemma of cache: two types of image

Jonathan Chetwynd wrote:

> 
> Organising this to work well for a single UA and server** is already far 
> too difficult.

Given that you use .htaccess, I don't see why.  Even without trying to 
manipulate cachability, it would be normal to put the library images and 
editorial ones in different directories.  All you then need is a 
.htaccess files in each directory.
> 

> ExpiresDefault A0 
> Header set Cache-Control "no-store, no-cache, must-revalidate, max-age=0"

This sort of sledge hammer approach to cache control is actually why 
people are unlikely to put much effort into the area (a large part of 
HTTP/1.0 is about optimising caching, but all that people seem to want 
to know is how to most throughly defeat it).  In practice, there tend to 
be two cachability classes:  never cache, and "I don't care about how it 
is cached".  Typically HTML gets the first treatment and images the 
second (in that case not having any control headers).

Specifically, in the above, I  believe:

no-cache has no (specified) effect when sent from the server;
must-revalidate is only meaningful if storing is allowed, so is 
incompatible with no-store;
no-store is intended to protect confidential data, not to guarantee 
freshness; it may do so, but it is too aggressive.

must-revalidate is probably enough here, although I think it would be 
better to set an expiry time of, say, ten minutes.  One may need 
Expires, for HTTP/1.0 caches.  I haven't re-reviewed the specification 
to look for what fine tuning might be appropriate.

In any case, it seems to me that this is about server and user agent 
aspects that are orthogonal to the SVG statndards, and about management 
and authoring policies.

-- 
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

Received on Thursday, 17 July 2008 21:37:33 UTC