Re: COUCHDB-190

[Zachary Zolton <za...@gmail.com>]

@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
<za...@gmail.com> 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 <jc...@apache.org> wrote:
>> On Sat, Jan 31, 2009 at 1:14 PM, Zachary Zolton
>> <za...@gmail.com> 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 <jc...@apache.org> wrote:
>>>> On Fri, Jan 30, 2009 at 10:41 PM, Antony Blakey <an...@gmail.com> 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
>>
>

Re: COUCHDB-190

[Paul Davis <pa...@gmail.com>]

On Wed, Feb 4, 2009 at 12:15 PM, Zachary Zolton
<za...@gmail.com> 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
> <za...@gmail.com> 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 <jc...@apache.org> wrote:
>>> On Sat, Jan 31, 2009 at 1:14 PM, Zachary Zolton
>>> <za...@gmail.com> 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 <jc...@apache.org> wrote:
>>>>> On Fri, Jan 30, 2009 at 10:41 PM, Antony Blakey <an...@gmail.com> 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
>>>
>>
>