couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lenz <>
Subject Re: Invalid ETag format
Date Sat, 10 May 2008 13:52:27 GMT
On 24.04.2008, at 15:47, Michael Wallner wrote:
> David Z├╝lke wrote:
>> There was a report, yup, filed it myself :)
>> It has been fixed in trunk as part of the mochiweb merge, apparently:
> Reads like it should be fixed, but seems like CouchDB doesn't send any
> ETags anymore:
> GET /phpunit_test1/3a801ba5a1b9df16a0cb4143c7839461?rev=2903083097  
> HTTP/1.1
> User-Agent: PECL::HTTP/1.6.1-dev (PHP/5.3.0-dev)
> Host: localhost:5984
> Accept: */*
> HTTP/1.1 200 OK
> Server: MochiWeb/1.0 (Any of you quaids got a smint?)
> Date: Thu, 24 Apr 2008 13:42:31 GMT
> Content-Type: text/plain;charset=utf-8
> X-Original-Transfer-Encoding: chunked
> Content-Length: 62
> {"_id":"3a801ba5a1b9df16a0cb4143c7839461","_rev":"2903083097"}

CouchDB now only sends Etags on document requests if the request URL  
doesn't specify any query string parameters. The rationale behind that  
is that some parameters, such as `revs_info`, can result in a  
different JSON value even for the same URI and document revision.

For example, you request a specific rev of a document with `? 
rev=123456&revs_info=true`; the next time you request the same  
resource, a new revision might have been added, which means the  
revision info in the JSON response will have a new entry, and thus the  
previously retrieved resource is no longer up to date. But if we added  
the revision as Etag to the response, caches will not know that the  
cached version is out of date. So for now CouchDB simply omits the  
Etag for any query string params.

In the future, it should be more intelligent, and only omit the Etag  
for "problematic" options. I.e. for a request with just a `? 
rev=123456` param, we should ideally still be including an Etag.

Christopher Lenz
   cmlenz at

View raw message