[
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15553952#comment-15553952
]
ASF subversion and git services commented on COUCHDB-3174:
----------------------------------------------------------
Commit 2cec875f2449dc0f747aa4759471da762d49ca85 in couchdb-documentation's
branch refs/heads/master from [~vatamane]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb-documentation.git;h=2cec875
]
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 be surprising for 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
> 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)
