- From: Bil Corry <bil@corry.biz>
- Date: Wed, 24 Jun 2009 16:32:18 -0500
- To: Jamie Lokier <jamie@shareable.org>
- CC: Henrik Nordstrom <henrik@henriknordstrom.net>, yngve@opera.com, Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Jamie Lokier wrote on 6/24/2009 3:41 PM: > Henrik Nordstrom wrote: >> mån 2009-06-15 klockan 16:42 +0200 skrev Yngve Nysaeter Pettersen: >> >>> As I said above: If they made the choice. In many cases I don't think they >>> did more than select a development environment that made the choice for >>> them, based on what is supposed to provide a "revalidate each time the >>> user clicks on a link to this document"-functionality, that is, the same >>> as "Cache-Control: max-age=0" and "no-cache". >> All environments I have seen support setting these kind of things if you >> care about them, and emit a default "do not cahe this response" header >> if the author / site developer using such environment don't care. Most >> people who don't care simply do not know, and quite happily try to >> accomodate for caching when they learn what it is. >> >> Blaiming the dev environment for emitting a safe low-performance default >> cache profile won't get us very far, neither is trying to work around >> this in the cache layer. This situation will persist, and any changes we >> make to the protocol will only get reflected in those dev environments >> using the new names, until the content/site developers gets their acts >> together. > > Absolutely. > > I think the main reason I've seen for dev environments disabling HTTP > caching is that occasionally, a developer changes the underlying files > which make up a site, and if caching is enabled, stale pages show in > the browser sometimes which is a _very_ annoying time sink when it's > not expected. 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. 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. > This may sound stupid, but you can tell it's important from the > significant number of web pages explaining how to disable HTTP caching > really really thoroughly on all clients and proxies. (Cache-Control: > no-cache,no-store,max-age=0; Pragma: no-cache; something like that.) 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? - Bil
Received on Wednesday, 24 June 2009 21:33:00 UTC