[
https://issues.apache.org/jira/browse/COUCHDB-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Newson resolved COUCHDB-1463.
------------------------------------
Resolution: Duplicate
Fix Version/s: 1.1.1
This issue was resolved in COUCHDB-1206.
The most likely explanation is that your Couchbase build does not include the
fix included in Apache CouchDB 1.1.1.
If you can induce the same error with the official 1.1.1 please reopen this
ticket.
> Do not return a 304 to a conditional view request when ?include_docs is
> specified
> ---------------------------------------------------------------------------------
>
> Key: COUCHDB-1463
> URL: https://issues.apache.org/jira/browse/COUCHDB-1463
> Project: CouchDB
> Issue Type: Bug
> Components: View Server Support
> Affects Versions: 1.1.1
> 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
> Reporter: Ewan Makepeace
> Fix For: 1.1.1
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
