On Wed, Feb 4, 2009 at 12:15 PM, Zachary Zolton <[email protected]> wrote: > @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? >
Just make sure you're git repo has been rebased to the latest trunk and then float your patch to the top and do a git diff. That should give a diff that patch can apply. HTH, Paul Davis > 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 >>> >> >
