You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by "Alexander Shorin (JIRA)" <ji...@apache.org> on 2015/05/25 01:19:17 UTC

[jira] [Closed] (COUCHDB-2700) multipart/related parsing broken when attachment contents change

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

Alexander Shorin closed COUCHDB-2700.
-------------------------------------
    Resolution: Not A Problem

The only place where this error may be raised in [/db/_bulk_docs|https://github.com/apache/couchdb/blob/1.6.1/src/couchdb/couch_httpd_db.erl#L294-L295] endpoint which doesn't supports multipart requests.

> multipart/related parsing broken when attachment contents change
> ----------------------------------------------------------------
>
>                 Key: COUCHDB-2700
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2700
>             Project: CouchDB
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: Database Core
>            Reporter: Nolan Lawson
>
> I can reliably reproduce a bug whereby CouchDB 1.6.1 throws this error:
> {code:javascript}
> {"status":400,"name":"content_md5_mismatch","message":"Missing JSON list of 'docs'"}
> {code}
> Unfortunately this is a really complicated test case, so it's prohibitively time-consuming for me to turn it into a set of CURL requests. Instead I've made a branch in the PouchDB codebase to reproduce this.
> Steps:
> {code}
> git clone https://github.com/pouchdb/pouchdb.git --depth 1 --branch 3871-repro-for-couchdb
> cd pouchdb
> npm install
> npm run dev
> {code}
> Once the dev server is running (takes a few seconds to start), open the following URL in Chrome:
> {code}
> http://localhost:8000/tests/integration/?grep=test.attachments.js-%20local%3Ahttp%20replication%20with%20changing%20attachments
> {code}
> The tests assume that you have a CouchDB running in admin party mode at {{localhost:5984}}. If that's not the case, you can set the CouchDB host like {{COUCH_HOST=http://path/to/couch:5984 npm run dev}}.
> You can see the PouchDB unit test itself [here | https://github.com/pouchdb/pouchdb/blob/3871-repro-for-couchdb/tests/integration/test.attachments.js#L2215-L2267]. It basically replicates a document between two databases several times, while changing the contents of the attachment (but keeping the attachment filename). Note that this test passes against PouchDB Server, where we are using [node-multiparty | https://www.npmjs.com/package/multiparty] for multipart parsing.
> In case it helps, I suspect the multipart parsing issue may also be related to a point [~isaacs] raised [in the npm fullfat repo | https://github.com/npm/npm-fullfat-registry/blob/2305c019740a7fd2f60fa1622842d6522a721b77/fullfat.js#L388-L390].
> Please also give me any insights into how to write a workaround for CouchDB 1.6, because I would still like to implement multipart support for older versions of CouchDB.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Closed] (COUCHDB-2700) multipart/related parsing broken when attachment contents change

Posted by Robert Kowalski <ro...@kowalski.gd>.
Nolan,

my Couch says:

```
[error] [<0.561.0>] Could not open file
/usr/local/var/lib/couchdb/test_attach_remote.couch: no such file or
directory
[info] [<0.274.0>] ::1 - - GET /test_attach_remote/?_nonce=1432515398129 404
[info] [<0.503.0>] ::1 - - PUT /test_attach_remote/ 201
[info] [<0.507.0>] ::1 - - GET
/test_attach_remote/_local/_pouch_dependentDbs?_nonce=1432515398208
404
[info] [<0.517.0>] ::1 - - DELETE /test_attach_remote/ 200
[error] [<0.578.0>] Could not open file
/usr/local/var/lib/couchdb/test_attach_remote.couch: no such file or
directory
[info] [<0.518.0>] ::1 - - GET /test_attach_remote/?_nonce=1432515398230 404
[info] [<0.519.0>] ::1 - - PUT /test_attach_remote/ 201
[info] [<0.520.0>] ::1 - - GET /?_nonce=1432515398309 200
[info] [<0.523.0>] ::1 - - GET
/test_attach_remote/_local/wM7iDnSu8mKpbzwHGB4uZg%3D%3D?_nonce=1432515398318
404
[info] [<0.524.0>] ::1 - - POST /test_attach_remote/_revs_diff 200
[info] [<0.525.0>] ::1 - - POST /test_attach_remote/_bulk_docs 201
[info] [<0.527.0>] ::1 - - GET
/test_attach_remote/_local/wM7iDnSu8mKpbzwHGB4uZg%3D%3D?_nonce=1432515398352
404
[info] [<0.526.0>] ::1 - - PUT
/test_attach_remote/_local/wM7iDnSu8mKpbzwHGB4uZg%3D%3D 201
[info] [<0.528.0>] ::1 - - GET
/test_attach_remote/bin_doc?_nonce=1432515398374 200
[info] [<0.531.0>] ::1 - - GET
/test_attach_remote/bin_doc/foo.txt?rev=2-8f82a9a5e7017a1e873227e8d9c093d9&_nonce=1432515398380
200
[info] [<0.532.0>] ::1 - - GET
/test_attach_remote/bin_doc/bar.txt?rev=2-8f82a9a5e7017a1e873227e8d9c093d9&_nonce=1432515398381
200
[info] [<0.533.0>] ::1 - - PUT /test_attach_remote/bin_doc 400
[info] [<0.560.0>] ::1 - - GET /test_attach_remote/?_nonce=1432515398406 200
[info] [<0.564.0>] ::1 - - GET
/test_attach_remote/_local/_pouch_dependentDbs?_nonce=1432515398414
404
[info] [<0.574.0>] ::1 - - DELETE /test_attach_remote/ 200
```

can you confirm this behaviour or did I do something wrong by running the tests?

On Mon, May 25, 2015 at 1:19 AM, Alexander Shorin (JIRA)
<ji...@apache.org> wrote:
>
>      [ https://issues.apache.org/jira/browse/COUCHDB-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Alexander Shorin closed COUCHDB-2700.
> -------------------------------------
>     Resolution: Not A Problem
>
> The only place where this error may be raised in [/db/_bulk_docs|https://github.com/apache/couchdb/blob/1.6.1/src/couchdb/couch_httpd_db.erl#L294-L295] endpoint which doesn't supports multipart requests.
>
>> multipart/related parsing broken when attachment contents change
>> ----------------------------------------------------------------
>>
>>                 Key: COUCHDB-2700
>>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2700
>>             Project: CouchDB
>>          Issue Type: Bug
>>      Security Level: public(Regular issues)
>>          Components: Database Core
>>            Reporter: Nolan Lawson
>>
>> I can reliably reproduce a bug whereby CouchDB 1.6.1 throws this error:
>> {code:javascript}
>> {"status":400,"name":"content_md5_mismatch","message":"Missing JSON list of 'docs'"}
>> {code}
>> Unfortunately this is a really complicated test case, so it's prohibitively time-consuming for me to turn it into a set of CURL requests. Instead I've made a branch in the PouchDB codebase to reproduce this.
>> Steps:
>> {code}
>> git clone https://github.com/pouchdb/pouchdb.git --depth 1 --branch 3871-repro-for-couchdb
>> cd pouchdb
>> npm install
>> npm run dev
>> {code}
>> Once the dev server is running (takes a few seconds to start), open the following URL in Chrome:
>> {code}
>> http://localhost:8000/tests/integration/?grep=test.attachments.js-%20local%3Ahttp%20replication%20with%20changing%20attachments
>> {code}
>> The tests assume that you have a CouchDB running in admin party mode at {{localhost:5984}}. If that's not the case, you can set the CouchDB host like {{COUCH_HOST=http://path/to/couch:5984 npm run dev}}.
>> You can see the PouchDB unit test itself [here | https://github.com/pouchdb/pouchdb/blob/3871-repro-for-couchdb/tests/integration/test.attachments.js#L2215-L2267]. It basically replicates a document between two databases several times, while changing the contents of the attachment (but keeping the attachment filename). Note that this test passes against PouchDB Server, where we are using [node-multiparty | https://www.npmjs.com/package/multiparty] for multipart parsing.
>> In case it helps, I suspect the multipart parsing issue may also be related to a point [~isaacs] raised [in the npm fullfat repo | https://github.com/npm/npm-fullfat-registry/blob/2305c019740a7fd2f60fa1622842d6522a721b77/fullfat.js#L388-L390].
>> Please also give me any insights into how to write a workaround for CouchDB 1.6, because I would still like to implement multipart support for older versions of CouchDB.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)