Will Holley created COUCHDB-3017:
------------------------------------
Summary: CouchDB 2.0: passing an invalid ETag to _changes
incorrectly returns 304 Not Modified
Key: COUCHDB-3017
URL: https://issues.apache.org/jira/browse/COUCHDB-3017
Project: CouchDB
Issue Type: Bug
Reporter: Will Holley
I discovered this issue whilst running the PouchDB test suite against CouchDB
2.0 (in a cluster of 1). It's a bit of an edge case but, essentially, the steps
to reproduce are:
1. create a database /foo
2. insert 2 empty documents with _ids "a" and "b"
3. call /foo/_changes?limit=1. Note the ETag returned in the response
4. delete /foo
5. recreate database /foo
6. insert 2 empty documents with _ids "a" and "b"
7. call /foo/_changes?limit=1, passing an "If-Not-Modified" header using the
ETag value captured in (3)
8. CouchDB 2.0 returns a 304 Not Modified response - CouchDB 1.6 returns a 200
and ignores the If-Not-Modified value
The problem for the client is that it would use the cached value from (3) which
is invalid for this recreated database.
A full reproduction is at
https://gist.github.com/willholley/c5f4c30fce822dc7dc48cbc8875c394b with the
CouchDB 1.6 equivalent at
https://gist.github.com/willholley/c0b9c6cf2a62090ac3bee4fa549644bd.
Bob Newson suggested that this was likely down to CouchDB 1.6 using the
instance_start_time when calculating the ETag for _changes, invaliding
previously returned ETags if a database is deleted and recreated with the same
parameters. In 2.0, instance_start_time is always 0 so we need to use a
different property to ensure unique ETags per database instance (e.g. the
unique shard suffix).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
