incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Davies <ja...@jasondavies.com>
Subject Re: Does CouchDB check autogenerated document id's?
Date Sat, 03 Jan 2009 13:43:42 GMT
On 3 Jan 2009, at 13:12, Noah Slater wrote:
> On Fri, Jan 02, 2009 at 04:52:29PM -0800, Chris Anderson wrote:
>> In the normal case you would POST a document to a collection when you
>> want the server to choose the final URL. However, intermediaries have
>> a habit of retrying POSTs randomly, so when you POST and id-less  
>> Couch
>> document, occasionally duplicate documents are created. We work  
>> around
>> this by recommending PUT as the document creation method. Of course
>> clients can specify any document id they'd like to, but for
>> lightweight clients CouchDB provides the _uuids service.
>>
>> The POST is pragmatic for cache-control reasons, but also RESTy,
>> because it exposes the service that CouchDB uses internally for
>> directing document POSTs to new ids. By using the _uuids service,
>> clients can become the part of CouchDB that would direct documents to
>> URLs in a collection.
>
> I don't agree and I think it should change to GET.
>
>  * You hint that it is to mirror the process required for the  
> creation of
>    documents. This is not how we should be designing the interface.  
> UUID
>    creation is totally disjoint and should be considered separately.
>
>  * You mention cache-control, but nothing about GET semantics implies
>    cacheability so unless there is some major flaw with common UA
>    implementations I don't see this as a valid argument.

After researching this in more depth it turns out I was indeed  
mistaken in thinking *any* responses to GET requests can potentially  
be cached.  Quoting from RFC 2616 [1]:

"The response to a GET request is cacheable if and only if it meets  
the requirements for HTTP caching described in section 13."

And section 13 [2] goes on to say that operations are transparent by  
default, and transparency can be relaxed:

       - only by an explicit protocol-level request when relaxed by
         client or origin server

       - only with an explicit warning to the end user when relaxed by
         cache or client

So as you say, unless common implementations have flaws, I think GET  
responses would not be cached unless we explicitly say so, assuming we  
handle the HEAD + If-Modified-Since etc. requests correctly (which is  
what a conforming cache proxy should do).

[1]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3
[2]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html

Jason
--
Jason Davies

www.jasondavies.com


Mime
View raw message