[
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15545495#comment-15545495
]
ASF subversion and git services commented on COUCHDB-3174:
----------------------------------------------------------
Commit 93c4ceaf97f46e0dd0fcc1deffe966263eda67d3 in couchdb-couch-replicator's
branch refs/heads/master from [~vatamane]
[
https://git-wip-us.apache.org/repos/asf?p=couchdb-couch-replicator.git;h=93c4cea
]
Add tests which check small values of max_document_size setting on the target
A low max_document_size setting on the target will interact with the replicator,
this commit adds a few tests to check that interaction.
There are 3 test scenarios:
* A basic test checks that individual document sizes can be smaller than
max_document_size yet, when batched together by the replicator they exceed,
the maximum size. Replicator in that case should split document batches into
halves down to individual documents, such that the replication should succeed.
* one_large_one_small test checks that a large single document should be
skipped such that it doesn't end on the target and it doesn't crash the
replication job (so the small document should reach the target).
* The third test is currently disable because of COUCHDB-3174. Once that
issue is fixed, it will test a corner case in replicator when it
switches from using batches and POST-ing to _bulk_docs to using individual
PUT's with multipart/mixed Content-Type. Those PUT request can also return
413 error code, so this tests it explicitly.
Jira: COUCHDB-3168
> max_document_size setting can by bypassed by issuing multipart/related
> requests
> -------------------------------------------------------------------------------
>
> Key: COUCHDB-3174
> URL: https://issues.apache.org/jira/browse/COUCHDB-3174
> Project: CouchDB
> Issue Type: Bug
> Reporter: Nick Vatamaniuc
> Attachments: attach_large.py
>
>
> Testing how replicator handled small values of max_document_size parameter,
> discovered if user issues PUT requests which are multipart/related, then
> max_document_size setting is bypassed.
> Wireshark capture of a PUT with attachments request coming from replicator in
> a EUnit test I wrote. max_document_size was set to 10000 yet a 70k byte
> document with a 70k byte attachment was created.
> {code}
> PUT /eunit-test-db-147555017168185/doc0?new_edits=false HTTP/1.1
> Content-Type: multipart/related; boundary="e5d21d5fd988dc1c6c6e8911030213b3"
> Content-Length: 140515
> Accept: application/json
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Type: application/json
> {"_id":"doc0","_rev":"1-40a6a02761aba1474c4a1ad9081a4c2e","x":"xxxx....
> ...xxxx","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":70000,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 70000
> xxxxx....xxxxx
> --e5d21d5fd988dc1c6c6e8911030213b3--
> HTTP/1.1 201 Created
> {code}
> Here is a regular request which works as expected:
> {code}
> PUT /dbl/dl2 HTTP/1.1
> Content-Length: 100026
> Content-Type: application/json
> Accept: application/json
> {"_id": "dl2", "size": "xxxx...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
