@jchris my git-to-svn-fu is kinda weak, and i could use some advice... here's the commits to my git repo: http://github.com/zdzolton/couchdb/commits/master
what's the best way to create a an svn diff for you guys? thanks, zdzolton On Sat, Jan 31, 2009 at 4:05 PM, Zachary Zolton <[email protected]> wrote: > 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 >> >
