[
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15544555#comment-15544555
]
Robert Newson commented on COUCHDB-3174:
----------------------------------------
ooh, good catch. We should probably just validate the size again after the
couch_doc_from_req calls, but this gets us back to the fact that
max_document_size is implemented as max request body size. In this case, where
a doc is followed by attachments in the same request body, we want to reject
the request because one part of it is too large.
If we want to add this check, and I believe we do, we should also adjust
_bulk_docs to apply the max_document_size restriction to each document too.
> 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)
