Chris/Antony, If we want to stop all caching, with a very generous helping of backward compatibility, let's consider responding with the following headers:
-------------------------------------------------------------------------------- Date: <ServercurrentDate> Expires: Fri, 01 Jan 1990 00:00:00 GMT Pragma: no-cache Cache-control: no-cache, must-revalidate -------------------------------------------------------------------------------- FYI, I found this article: http://code.google.com/p/doctype/wiki/ArticleHttpCaching Cheers, Zach On Sat, Jan 31, 2009 at 1:01 AM, Chris Anderson <[email protected]> wrote: > On Fri, Jan 30, 2009 at 10:41 PM, Antony Blakey <[email protected]> > wrote: >> >> In the referenced m/l discussion about the issue of GET vs. POST, the point >> was made that if there are problems with GET for UUIDs, then there are going >> to be similar problems for GETs of documents, views without params, >> /_config, /_stats etc, and attachments. >> > > True, but in those cases at least the failure mode manifests itself in > ways other than rejecting later updates. Also, in those cases there > are conditions when it's OK to cache. In the _uuids case, one should > never ever cache. > >> I would have thought that GET of UUIDs would therefore be OK as long as it >> was at least as good cache-header-wise as the other GET operations in >> CouchDB. >> > > Good point, I guess I'm thinking it doesn't hurt to be as uncacheable > as possible in this case. But you raise the point that bad clients are > going to get strange errors regardless of what we do on this question, > so being helpful to nonconforming clients is of limited value. > > @ZDZolton: testing for > > Cache-Control: must-revalidate > > is important. This snippet from the RFC: > > (I.e., the cache MUST do an end-to-end revalidation every time, if, > based solely on the origin server's Expires or max-age value, the > cached response is stale.) > > suggests we should also test for either Expires or max-age, to be on > the safe side. > > Chris > > -- > Chris Anderson > http://jchris.mfdz.com >
