[
https://issues.apache.org/jira/browse/COUCHDB-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15888685#comment-15888685
]
ASF GitHub Bot commented on COUCHDB-2295:
-----------------------------------------
Github user tonysun83 commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/156
@davisp: You're right, I was confusing the streaming of requests with
header Transfer-Encoding: chunked. Just because multipart requests are streamed
doesn't mean that it used Transfer-Encoding:chunked. It can use
Transfer-Encoding:chunked, and that is where it's a little more complex.
Interestingly, the special situation where we do both multipart + chunked is
still broken?
https://issues.apache.org/jira/browse/COUCHDB-2295
We also have to figure out what happens when we upgrade a cluster and the
document size is set to something small and now all of a sudden certain
documents can't be updated because they exceed the limit.
> Connection hangs on document update for multipart/related and transfer
> encoding chunked request
> -----------------------------------------------------------------------------------------------
>
> Key: COUCHDB-2295
> URL: https://issues.apache.org/jira/browse/COUCHDB-2295
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
> Reporter: Alexander Shorin
> Fix For: 1.7.0
>
>
> Script to reproduce:
> {code}
> import pprint
> import requests
> body = [
> b'--996713c691ec4fd5b717ef2740893b78\r\n',
> b'Content-Type: application/json\r\n',
> b'\r\n',
> b'{"_id": "test","_attachments": {"foo": {"follows": true,
> "content_type": "text/plain", "length": 12}}}\r\n',
> b'--996713c691ec4fd5b717ef2740893b78\r\n',
> b'Content-Type: text/plain\r\n'
> b'Content-Disposition: attachment;filename="foo"\r\n'
> b'Content-Length: 12\r\n'
> b'\r\n',
> b'Time to Relax!',
> b'--996713c691ec4fd5b717ef2740893b78--\r\n'
> ]
> url = 'http://localhost:5984/db/test'
> headers = {
> 'Content-Type': 'multipart/related;
> boundary="996713c691ec4fd5b717ef2740893b78"'
> }
> resp = requests.put(url, headers=headers, data=iter(body))
> pprint.pprint(resp.json())
> {code}
> This runs a request:
> {code}
> PUT /db/test HTTP/1.1
> Host: localhost:5984
> Accept-Encoding: gzip, deflate
> Transfer-Encoding: chunked
> User-Agent: python-requests/2.3.0 CPython/3.4.1 Linux/3.15.5-gentoo
> Accept: */*
> Content-Type: multipart/related; boundary="996713c691ec4fd5b717ef2740893b78"
> 24
> --996713c691ec4fd5b717ef2740893b78
> 20
> Content-Type: application/json
> 2
> 68
> {"_id": "test","_attachments": {"foo": {"follows": true, "content_type":
> "text/plain", "length": 14}}}
> 24
> --996713c691ec4fd5b717ef2740893b78
> 60
> Content-Type: text/plain
> Content-Disposition: attachment;filename="foo"
> Content-Length: 12
> e
> Time to Relax!
> 26
> --996713c691ec4fd5b717ef2740893b78--
> 0
> {code}
> But connection hangs: CouchDB thinks that there have to more data while zero
> length chunk had been send and doesn't reply with anything back to client
> which had finished the request and awaits for the response.
> The problem could be "fixed" by specifying full Content-Length of multipart
> body in request, which kills all the idea of chunked transfer.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
