On Sat, Jan 31, 2009 at 1:14 PM, Zachary Zolton <[email protected]> wrote: > 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 > -------------------------------------------------------------------------------- >
sounds good to me. I'm +1 on including a patch that test for these headers for _uuids GET requests > 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 >> > -- Chris Anderson http://jchris.mfdz.com
