[jira] [Created] (COUCHDB-3017) CouchDB 2.0: passing an invalid ETag to _changes incorrectly returns 304 Not Modified

["Will Holley (JIRA)" <ji...@apache.org>]

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)