Re: dilemma of cache: two types of image

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:
> http://www.openicon.org/iconChat/index.svg
> http://www.openicon.org/feeds/zanadu.svg

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 07:30:38 UTC