[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2017-04-25 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983605#comment-15983605
 ] 

ASF subversion and git services commented on COUCHDB-3174:
--

Commit e5550fbd9ad3ee97cd90b01bd8162e38bd3f9299 in couchdb's branch 
refs/heads/COUCHDB-3377 from [~vatamane]
[ https://gitbox.apache.org/repos/asf?p=couchdb.git;h=e5550fb ]

Merge pull request #489 from 
cloudant/COUCHDB-3174-re-enable-attachment-replication-tests

Re-enable attachment replication tests

> 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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2017-04-25 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983010#comment-15983010
 ] 

ASF subversion and git services commented on COUCHDB-3174:
--

Commit e5550fbd9ad3ee97cd90b01bd8162e38bd3f9299 in couchdb's branch 
refs/heads/63012-scheduler from [~vatamane]
[ https://gitbox.apache.org/repos/asf?p=couchdb.git;h=e5550fb ]

Merge pull request #489 from 
cloudant/COUCHDB-3174-re-enable-attachment-replication-tests

Re-enable attachment replication tests

> 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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2017-04-25 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15982996#comment-15982996
 ] 

ASF subversion and git services commented on COUCHDB-3174:
--

Commit e5550fbd9ad3ee97cd90b01bd8162e38bd3f9299 in couchdb's branch 
refs/heads/master from [~vatamane]
[ https://gitbox.apache.org/repos/asf?p=couchdb.git;h=e5550fb ]

Merge pull request #489 from 
cloudant/COUCHDB-3174-re-enable-attachment-replication-tests

Re-enable attachment replication tests

> 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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2017-04-25 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15982995#comment-15982995
 ] 

ASF subversion and git services commented on COUCHDB-3174:
--

Commit a5e3deba154974c05ffd70d1b0002ddebeb013a8 in couchdb's branch 
refs/heads/master from [~jaydoane]
[ https://gitbox.apache.org/repos/asf?p=couchdb.git;h=a5e3deb ]

Re-enable attachment replication tests

These tests now pass.

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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2016-10-10 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15562476#comment-15562476
 ] 

ASF subversion and git services commented on COUCHDB-3174:
--

Commit 554be3a1be4f6e3934fa0e1bf4991009915e0872 in couchdb's branch 
refs/heads/master from [~vatamane]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=554be3a ]

Bump couch for a typo fix

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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



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

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2016-10-07 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1296#comment-1296
 ] 

ASF GitHub Bot commented on COUCHDB-3174:
-

Github user nickva closed the pull request at:

https://github.com/apache/couchdb-documentation/pull/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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



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

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2016-10-07 Thread Nick Vatamaniuc (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1211#comment-1211
 ] 

Nick Vatamaniuc commented on COUCHDB-3174:
--

The issue is not 100% fixed, but it should help against accidental cases

> 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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



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

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2016-10-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15554118#comment-15554118
 ] 

ASF subversion and git services commented on COUCHDB-3174:
--

Commit 313f6f3f9a722dc1c88de1e809ae28c8bc741970 in couchdb's branch 
refs/heads/master from [~vatamane]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=313f6f3 ]

Bump chttpd, couch and docs for max_document_size fixes.

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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



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

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2016-10-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



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

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2016-10-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



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

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2016-10-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15553221#comment-15553221
 ] 

ASF subversion and git services commented on COUCHDB-3174:
--

Commit 5d7170c472d2ca72d4a0dd41eb7ae4434266be7d in couchdb-chttpd's branch 
refs/heads/master from [~vatamane]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb-chttpd.git;h=5d7170c ]

Add max_document_size checking for multipart PUT requests

Previously multipart/related PUT requests didn't check maximum request sizes.

This commit checks content-length and compares that with the maximum.

This means keeping the current "semantics" of max_document_size which actually
means "max request size". But this makes the check more efficient and can
be done earlier in request processing time.

PR depends on https://github.com/apache/couchdb-couch/pull/201 make sure to
merge that one first if accepted.

Jira: 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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



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

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2016-10-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15553222#comment-15553222
 ] 

ASF GitHub Bot commented on COUCHDB-3174:
-

Github user asfgit closed the pull request at:

https://github.com/apache/couchdb-chttpd/pull/143


> 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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



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

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2016-10-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15553210#comment-15553210
 ] 

ASF GitHub Bot commented on COUCHDB-3174:
-

Github user asfgit closed the pull request at:

https://github.com/apache/couchdb-couch/pull/201


> 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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



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

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2016-10-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15553208#comment-15553208
 ] 

ASF subversion and git services commented on COUCHDB-3174:
--

Commit 7dec013e8dc12db718ce124ad07f62b7cd3f7419 in couchdb-couch's branch 
refs/heads/master from [~vatamane]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb-couch.git;h=7dec013 ]

Add max_document_size checking for multipart PUT requests

Previously multipart/related PUT requests didn't check maximum request sizes.

This commit checks content-length and compares that with the maximum.

This means keeping the current "semantics" of max_document_size which actually
means "max request size". But this makes the check more efficient and can
be done earlier in request processing time.

Jira: 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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



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

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2016-10-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15553173#comment-15553173
 ] 

ASF GitHub Bot commented on COUCHDB-3174:
-

Github user davisp commented on the issue:

https://github.com/apache/couchdb-couch/pull/201
  
+1 but we'll want to document the new behavior somewhere. Also, you don't 
need the Jira: in front of your COUCHDB-3174 in the commit message.


> 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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



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

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2016-10-04 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15544564#comment-15544564
 ] 

ASF GitHub Bot commented on COUCHDB-3174:
-

GitHub user nickva opened a pull request:

https://github.com/apache/couchdb-chttpd/pull/143

Add max_document_size checking for multipart PUT requests

Previously multipart/related PUT requests didn't check maximum request 
sizes.

This commit checks content-length and compares that with the maximum.

This means keeping the current "semantics" of max_document_size which 
actually
means "max request size". But this makes the check more efficient and can
be done earlier in request processing time.

PR depends on https://github.com/apache/couchdb-couch/pull/201 make sure to
merge that one first if accepted.

Jira: COUCHDB-3174

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cloudant/couchdb-chttpd couchdb-3174

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/couchdb-chttpd/pull/143.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 #143


commit 5d7170c472d2ca72d4a0dd41eb7ae4434266be7d
Author: Nick Vatamaniuc 
Date:   2016-10-04T06:58:32Z

Add max_document_size checking for multipart PUT requests

Previously multipart/related PUT requests didn't check maximum request 
sizes.

This commit checks content-length and compares that with the maximum.

This means keeping the current "semantics" of max_document_size which 
actually
means "max request size". But this makes the check more efficient and can
be done earlier in request processing time.

PR depends on https://github.com/apache/couchdb-couch/pull/201 make sure to
merge that one first if accepted.

Jira: 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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



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

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2016-10-04 Thread Robert Newson (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



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

[jira] [Commented] (COUCHDB-3174) max_document_size setting can by bypassed by issuing multipart/related requests

2016-10-03 Thread Nick Vatamaniuc (JIRA) 

[ 
https://issues.apache.org/jira/browse/COUCHDB-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15544234#comment-15544234
 ] 

Nick Vatamaniuc commented on COUCHDB-3174:
--

The problem seems to be here:

https://github.com/apache/couchdb-chttpd/blob/master/src/chttpd_db.erl#L763-L776

and here:

https://github.com/apache/couchdb-chttpd/blob/master/src/chttpd_db.erl#L763-L776

We need to call the json_body bit in order to get the max document size which 
is passed to `MochiReq:recv_body(MaxSize)`.

Presumably we could retrieve Content-Length ourselves before mp parsing and 
raise a 413, but I haven't thought about it too much yet...

> 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
>
> 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 1 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":"
> ...","_revisions":{"start":1,"ids":["40a6a02761aba1474c4a1ad9081a4c2e"]},"_attachments":{"att1":{"content_type":"app/binary","revpos":1,"digest":"md5-u+COd6RLUd6BGz0wJyuZFg==","length":7,"follows":true}}}
> --e5d21d5fd988dc1c6c6e8911030213b3
> Content-Disposition: attachment; filename="att1"
> Content-Type: app/binary
> Content-Length: 7
> xx
> --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": "...xxx"}
> HTTP/1.1 413 Request Entity Too Large
> {code}



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