- From: Jamie Lokier <jamie@shareable.org>
- Date: Thu, 25 Jun 2009 01:46:50 +0100
- To: Bil Corry <bil@corry.biz>
- Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, yngve@opera.com, Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Bil Corry wrote: > For web applications with dynamic content, it is easier to just > prevent caching than it is to implement a system to handle > If-Modified-Since. Expires header isn't an option when the content > can change at any given moment. I use Etags. The ETags are generated from all the prerequisites to the dynamic content as accurately as possible. E.g. a combined result of all the file timestamps and sizes which are used to make the content, and database cache tags. I agree that it's not entirely easy, although good frameworks usually have a way to encapsulate it. > Of course, that's for HTML content; for media assets (png, jpg, > etc), we use the Expires header to prevent any further requests for it. I do similar. For dynamically generated images, I set Expires 1 year into the future, and use a hash of the image, either of the image file itself or the instructions used to generate it, and use the hash as part of the URL of the image. That way it can be dynamic but only fetched when it changes, by the HTML which references it changing automatically. It's a bit complicated, but it can be hidden well in the guts of a server and performs well. > That's the reason you see the shotgun approach to preventing > caching; different browsers (and legacy browsers) and proxies respond > to different headers. And even then, I still hear about users behind > a corporate proxy that serves cached content from one to another, > causing User A to see User B's information. > > Is there a resource that gives the "official" way to prevent caching > across all browsers and proxies? I don't think there is any "official" method which considers all real implementations. Official and implementation are in constant tension. As your example shows, there might not be any way. Some ancient caches just have a fixed expiry age configured. The ultimate method is to keep changing the URL. (Similar to the way some frameworks change the names of form elements, to prevent browsers from pre-filling forms with wrong sensitive data by accident). This is what I've found, for the paranoid: Pragma: no-cache Cache-Control: no-cache,max-age=0,must-revalidate,pre-check=0,post-check=0 Expires: VERY-OLD-DATE The apparently redundant fields are in case of implementations which don't understand, or don't correctly implement, the other fields. There's probably a browser out there which doesn't understand "Cache-Control: no-cache,..." when there's anything else on the same line. IE had a reputation for being a bit rigid in how it recognises some headers. But I'm pretty sure anything like that will recognise "Pragma: no-cache" so it doesn't matter. -- Jamie
Received on Thursday, 25 June 2009 00:47:30 UTC