couchdb-dev mailing list archives

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

     [ 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

        

Mime
View raw message