W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: httpbis-p6-cache-06 and no-store response directive

From: Bil Corry <bil@corry.biz>
Date: Wed, 24 Jun 2009 16:32:18 -0500
Message-ID: <4A429B62.3040606@corry.biz>
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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC