I'll have to send in another patch soon, to generate these headers and test for them.
On Sat, Jan 31, 2009 at 3:38 PM, Chris Anderson <[email protected]> wrote: > 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 >
