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

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

     [ https://issues.apache.org/jira/browse/COUCHDB-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Will Holley resolved COUCHDB-3017.
----------------------------------
       Resolution: Fixed
    Fix Version/s: 2.0.0

Verified fixed in master

> 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
>    Affects Versions: 2.0.0
>            Reporter: Will Holley
>             Fix For: 2.0.0
>
>
> 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-None-Match" 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-None-Match 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)