couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zachary Zolton <zachary.zol...@gmail.com>
Subject Re: COUCHDB-190
Date Sat, 31 Jan 2009 22:05:13 GMT
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 <jchris@apache.org> wrote:
> On Sat, Jan 31, 2009 at 1:14 PM, Zachary Zolton
> <zachary.zolton@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 <jchris@apache.org> wrote:
>>> On Fri, Jan 30, 2009 at 10:41 PM, Antony Blakey <antony.blakey@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
>

Mime
View raw message