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:
https://issues.apache.org/jira/browse/COUCHDB-13
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.
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
