You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Zachary Zolton <za...@gmail.com> on 2009/01/31 06:50:31 UTC
COUCHDB-190
So, I've had a patch there, for a few days. I'll provide explanation,
if you want to commit...
Re: COUCHDB-190
Posted by 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
>>>
>>
>
Re: COUCHDB-190
Posted by 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
Posted by Zachary Zolton <za...@gmail.com>.
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
Posted by Chris Anderson <jc...@apache.org>.
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
Posted by Zachary Zolton <za...@gmail.com>.
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
--------------------------------------------------------------------------------
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
>
Re: COUCHDB-190
Posted by Chris Anderson <jc...@apache.org>.
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
Re: COUCHDB-190
Posted by Antony Blakey <an...@gmail.com>.
On 31/01/2009, at 4:59 PM, Chris Anderson wrote:
> Part of the point of using POST was to avoid all the compatibility
> questions with non-conforming user-agents. I understand that bending
> over backwards for broken UA's is not the best way to go (hence my
> interest in the patch) but I think we'd do well to go above and beyond
> the spec here.
>
> From my bad-old days as an IE jockey, I seem to remember some stuff
> about Pragma: no-cache. I'm not sure if we have a CouchDB policy about
> supporting HTTP 1.0, but unless we can be sure that switching to GET
> won't introduce some uncontrollable regressions for old or bad user
> agents, I think we should at least continue to support POST as well as
> GET.
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.
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.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
A Man may make a Remark –
In itself – a quiet thing
That may furnish the Fuse unto a Spark
In dormant nature – lain –
Let us divide – with skill –
Let us discourse – with care –
Powder exists in Charcoal –
Before it exists in Fire –
-– Emily Dickinson 913 (1865)
Re: COUCHDB-190
Posted by Chris Anderson <jc...@apache.org>.
On Fri, Jan 30, 2009 at 10:13 PM, Zachary Zolton
<za...@gmail.com> wrote:
> JChris,
>
> Would testing for the this header be sufficient?
>
> Cache-Control: must-revalidate
>
Part of the point of using POST was to avoid all the compatibility
questions with non-conforming user-agents. I understand that bending
over backwards for broken UA's is not the best way to go (hence my
interest in the patch) but I think we'd do well to go above and beyond
the spec here.
>From my bad-old days as an IE jockey, I seem to remember some stuff
about Pragma: no-cache. I'm not sure if we have a CouchDB policy about
supporting HTTP 1.0, but unless we can be sure that switching to GET
won't introduce some uncontrollable regressions for old or bad user
agents, I think we should at least continue to support POST as well as
GET.
Here's a pretty good summary of the problems with old IE versions and
GET caches:
http://www.quirksmode.org/blog/archives/2005/12/xmlhttp_notes_c.html
If you can convince me that it's safe just to do GET correctly in
2008, I'm happy to go through with the patch. Since duplicate uuids
have a hard-to-trace failure mode, and POST isn't causing any
pragmatic problems, the only reason I can see to move to GET is that
it's a good example it sets for other servers.
> Given the quotation:
>
> "Servers SHOULD send the must-revalidate directive if and only if
> failure to revalidate a request on the entity could result in
> incorrect operation, such as a silently unexecuted financial
> transaction."
>
> From:
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
>
>
> Cheers,
>
> ZDZolton
>
>
> On Fri, Jan 30, 2009 at 11:54 PM, Chris Anderson <jc...@apache.org> wrote:
>> On Fri, Jan 30, 2009 at 9:50 PM, Zachary Zolton
>> <za...@gmail.com> wrote:
>>> So, I've had a patch there, for a few days. I'll provide explanation,
>>> if you want to commit...
>>>
>>
>> Thanks for the reminder. The only thing I'd ask for is adding to the
>> test suite, a verification that the proper cache control headers are
>> being sent. It may be that they already are, but since it's absolutely
>> crucial for correct client behavior, adding a test for it will ensure
>> that we don't face a future regression.
>>
>> Thanks,
>> Chris
>>
>> --
>> Chris Anderson
>> http://jchris.mfdz.com
>>
>
--
Chris Anderson
http://jchris.mfdz.com
Re: COUCHDB-190
Posted by Zachary Zolton <za...@gmail.com>.
JChris,
Would testing for the this header be sufficient?
Cache-Control: must-revalidate
Given the quotation:
"Servers SHOULD send the must-revalidate directive if and only if
failure to revalidate a request on the entity could result in
incorrect operation, such as a silently unexecuted financial
transaction."
From:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
Cheers,
ZDZolton
On Fri, Jan 30, 2009 at 11:54 PM, Chris Anderson <jc...@apache.org> wrote:
> On Fri, Jan 30, 2009 at 9:50 PM, Zachary Zolton
> <za...@gmail.com> wrote:
>> So, I've had a patch there, for a few days. I'll provide explanation,
>> if you want to commit...
>>
>
> Thanks for the reminder. The only thing I'd ask for is adding to the
> test suite, a verification that the proper cache control headers are
> being sent. It may be that they already are, but since it's absolutely
> crucial for correct client behavior, adding a test for it will ensure
> that we don't face a future regression.
>
> Thanks,
> Chris
>
> --
> Chris Anderson
> http://jchris.mfdz.com
>
Re: COUCHDB-190
Posted by Chris Anderson <jc...@apache.org>.
On Fri, Jan 30, 2009 at 9:50 PM, Zachary Zolton
<za...@gmail.com> wrote:
> So, I've had a patch there, for a few days. I'll provide explanation,
> if you want to commit...
>
Thanks for the reminder. The only thing I'd ask for is adding to the
test suite, a verification that the proper cache control headers are
being sent. It may be that they already are, but since it's absolutely
crucial for correct client behavior, adding a test for it will ensure
that we don't face a future regression.
Thanks,
Chris
--
Chris Anderson
http://jchris.mfdz.com