couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Shorin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-2295) Connection hangs on document update for multipart/related and transfer encoding chunked request
Date Sun, 17 Aug 2014 17:52:18 GMT

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

Alexander Shorin commented on COUCHDB-2295:
-------------------------------------------

Yes, you're right about receive_request_data/2 - I just was satisfied by understanding that
things are going wrong there for chunked response.

Replicator sends multipart requests with content length and without chunked transfer, avoiding
the issue. I believe, this is also a place for replication optimization since to send a doc
with 2 GB attachment it has to read it whole into the memory to calculate length properly.
Otherwise it could just try to stream it right from db file by chunks.

I'm fine with quick fix while proper one will get baked. 

> 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
>      Security Level: public(Regular issues) 
>          Components: HTTP Interface
>            Reporter: Alexander Shorin
>
> 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.2#6252)

Mime
View raw message