couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zachary Zolton <>
Subject Re: COUCHDB-190
Date Sat, 31 Jan 2009 21:14:02 GMT

If we want to stop all caching, with a very generous helping of
backward compatibility, let's consider responding with the following

  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:



On Sat, Jan 31, 2009 at 1:01 AM, Chris Anderson <> wrote:
> On Fri, Jan 30, 2009 at 10:41 PM, Antony Blakey <> 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

View raw message