Uploaded image for project: 'CouchDB'
  1. CouchDB
  2. COUCHDB-3017

CouchDB 2.0: passing an invalid ETag to _changes incorrectly returns 304 Not Modified

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.0.0
    • Component/s: None
    • Labels:
      None

      Description

      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).

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              wilhol Will Holley
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: