[
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15553361#comment-15553361
]
ASF GitHub Bot commented on COUCHDB-3174:
-----------------------------------------
GitHub user nickva opened a pull request:
https://github.com/apache/couchdb-documentation/pull/78
Update max_document_size description with correct semantics
`max_document_size` is a misnomer and is actually implemented as the
equivalent of `max_http_recv_body_size`. That is, it checks the total
HTTP request body size. In case of multiple documents (_bulk_docs)
or attachments, there could be a large discrepancy between the two which can
and that can be surprising for the users.
In the future we could deprecate this setting, rename it, or have an actual
check for individual document sizes, however for now it is better to inform
users of current behavior.
COUCHDB-3174
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/cloudant/couchdb-documentation couchdb-3174
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/couchdb-documentation/pull/78.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #78
----
----
> 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)
