Re: dilemma of cache: two types of image


the examples are merely that, some images remain the same from week to  
week others change second by second.

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

similarly arranging preferences for current UA across a range of sites  
is pretty close to impossible.

creating a simple and easy to use AT that might set this up is at best  


Jonathan Chetwynd

+44 (0) 20 7978 1764

**re no-cache, this was short-hand, please find my actual .htaccess  
file attached

AddType image/svg+xml svg svgz
AddEncoding x-gzip .gz .tgz .svgz .svg.gz
ExpiresDefault A0
Header set Cache-Control "no-store, no-cache, must-revalidate, max- 
Header set Pragma "no-cache"

On 17 Jul 2008, at 08:31, David Woolley wrote:

> Jonathan Chetwynd wrote:
>>  dilemma of cache: two types of image
>> People who rely on images to communicate may prefer to cache them  
>> locally.
>> however in order to keep up with news, blogs, webchat etc it's  
>> necessary to ensure the content is fresh.
>> One workaround is to ensure the server sends a no-cache header for
> There is no such header and, according to a literal reading of the  
> specification, pragma: no-cache doesn't do what people think it does  
> (work from server to browser), even though browsers may actually  
> honour it from servers.
> The best way of handling this is to use proper expiry controls (e.g.  
> max-age) in the cache-control header, so that everything is  
> cachable, but library images are cached for weeks and news images  
> for minutes.  If one wants an absolute block, the correct cache- 
> control option is actually no-store, although the rationale for this  
> is actually security.
> For larger images, one can use cache-control: must-revalidate,  
> together with a liberal expiry time, to force an If-Modified-Since  
> request when the browser or intermediate cache might otherwise use a  
> cached copy. This allows a cached copy to be used, but ensures that  
> it is up to date.
>> non-library content and the browser is set to check weekly.
>> However not all servers may be set this way, and not all users will  
>> chose or know to set their browsers.
> I think all servers in serious use can be configured properly.  The  
> real problem is a commercial one in that ISPs can charge extra for  
> allowing content providers to properly configure the server.  There  
> are also some security implications in being able to configure the  
> server.
>> eg in Opera the relevant cache settings are labelled images and  
>> documents, and presumably refer to html rather than svg.
> I don't see a proposal here, but one other thing to note is that  
> shared caches do not act on in-content meta-information.  In  
> practice, they are often configured to default to long expiry times  
> on images, because authors tend not to specify expiry times at all  
> for images (and often try to defeat caching on all HTML, whether or  
> not appropriate to do so, a factor which can lead shared caches to  
> cache even when told not to).
> Any mechanism needs to be based only on HTTP headers.
>> for example:
> These examples need an explanation of how their specific parts  
> relate to caching policies.  I was expecting proposal documents not  
> sample images.
> -- 
> 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 13:50:06 UTC