Re: dilemma of cache: two types of image

David,

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  
unlikely.

regards



Jonathan Chetwynd

j.chetwynd@btinternet.com
http://www.openicon.org/

+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- 
age=0"
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:
>> 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.
>