couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (COUCHDB-1463) Do not return a 304 to a conditional view request when ?include_docs is specified
Date Fri, 13 Apr 2012 10:51:18 GMT

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

Robert Newson updated COUCHDB-1463:
-----------------------------------

    Affects Version/s:     (was: 1.1.1)

removing 'affects 1.1.1' as this is not the version used by the original reporter.
                
> 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
>         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

        

Mime
View raw message