[COUCHDB-1463] Do not return a 304 to a conditional view request when ?include_docs is specified

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Duplicate
• Fix Version/s: 1.1.1
• Component/s: View Server Support

Environment

Mac running Lion, Google Chrome browser for Mac 19.0.1084.15 beta
Running on CouchBase single server 2.0b which is CDB 1.1.X

• Skill Level: Regular Contributors Level (Easy to Medium)
• Assignee: Unassigned
• Reporter: Ewan Makepeace
• Created: 13/Apr/12 06:51
• Updated: 14/Apr/12 10:14
• Resolved: 13/Apr/12 10:41

Description

We are getting stale pages using views with the ?include_docs parameter as follows:

1) Edit some document fields and save them (only fields not contained in either view keys or values were changed)
2) Return to the list page driven by a view
3) Edits are not showing on the list page - displayed data is stale.

After investigation this seems to be due to caching of the view results in the browser. If I flush the browser caches the stale data disappears. However I am guessing that the browser makes a HEAD request for the URL to CouchDB and is told that the cached view is good (since the view has not changed since last access). However this is incorrect - the data returned by ?include_docs has changed and so the cache is stale.

To reproduce:

1) Make a database called includedocs

2) Add a document such as:
{
"_id": "06d86659f684c5969d2f1bb5d201c274",
"_rev": "6-1bb578b525f1c24afe3f57b8271f843a",
"field1": 1,
"field2": 6
}

3) Add a simple view operating on field 1:
function(doc)

{ emit("Field1", doc.field1); } 4) Test the view: http://127.0.0.1:5984/includedocs/_design/field1/_view/field1 {"total_rows":1,"offset":0,"rows":[ {"id":"06d86659f684c5969d2f1bb5d201c274","key":"Field1","value":1}

]}

5) Test with include docs: http://127.0.0.1:5984/includedocs/_design/field1/_view/field1?include_docs=true
{"total_rows":1,"offset":0,"rows":[
{"id":"06d86659f684c5969d2f1bb5d201c274","key":"Field1","value":1,"doc":{"_id":"06d86659f684c5969d2f1bb5d201c274","_rev":"6-1bb578b525f1c24afe3f57b8271f843a","field1":1,"field2":6}}
]}

6) NOTE: Returned document has latest revision (6). Now edit the document changing only Field2 so that the view is not affected:
{
"_id": "06d86659f684c5969d2f1bb5d201c274",
"_rev": "7-3e72418b297a1908820579f5506a4ec0",
"field1": 1,
"field2": 7
}

7) Refresh the View page from step 5:
{"total_rows":1,"offset":0,"rows":[
{"id":"06d86659f684c5969d2f1bb5d201c274","key":"Field1","value":1,"doc":{"_id":"06d86659f684c5969d2f1bb5d201c274","_rev":"6-1bb578b525f1c24afe3f57b8271f843a","field1":1,"field2":6}}
]}

8) NOTE: My view just returned stale data - revision is still 6. To confirm I now compact my database and refresh the page again:
{"total_rows":1,"offset":0,"rows":[
{"id":"06d86659f684c5969d2f1bb5d201c274","key":"Field1","value":1,"doc":{"_id":"06d86659f684c5969d2f1bb5d201c274","_rev":"6-1bb578b525f1c24afe3f57b8271f843a","field1":1,"field2":6}}
]}

9) No change - the view is now returning deleted revisions. I flush my Chrome Cache and refresh:
{"total_rows":1,"offset":0,"rows":[
{"id":"06d86659f684c5969d2f1bb5d201c274","key":"Field1","value":1,"doc":{"_id":"06d86659f684c5969d2f1bb5d201c274","_rev":"7-3e72418b297a1908820579f5506a4ec0","field1":1,"field2":7}}
]}

10) BINGO! The view is now returning the current document.

Looking in my CouchDB log I see lines like this:

[info] [<0.5140.11>] 127.0.0.1 - - GET /includedocs/_design/field1/_view/field1?include_docs=true 304

while the last one shows

[info] [<0.5140.11>] 127.0.0.1 - - GET /includedocs/_design/field1/_view/field1?include_docs=true 200

10.3.5 304 Not Modified
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.

So the browser does a conditional request, CouchDB says the data has not changed but it has.

Issue Links

• is duplicated by: COUCHDB-1206 View ETags may be incorrect if ?include_docs=true is specified