[
https://issues.apache.org/jira/browse/COUCHDB-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497290#comment-13497290
]
Jan Lehnardt commented on COUCHDB-1368:
---------------------------------------
The main CouchDB repo lives here:
https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=summary
Branches are not mirrored to GitHub at this point (sorry), but I pushed it to
my fork:
https://github.com/janl/couchdb/tree/1368-fix-multipart-header-parts.
The commit in question:
https://github.com/janl/couchdb/commit/18971de71c93c3a00e408b3d4eb67be8c695150c
Here’s a request dump:
> curl -Nv $COUCH/test/asd?attachments=true -H "Accept: multipart/related,*/*;"
* About to connect() to 127.0.0.1 port 5984 (#0)
* Trying 127.0.0.1...
* connected
* Connected to 127.0.0.1 (127.0.0.1) port 5984 (#0)
> GET /test/asd?attachments=true HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0
> OpenSSL/0.9.8r zlib/1.2.5
> Host: 127.0.0.1:5984
> Accept: multipart/related,*/*;
>
< HTTP/1.1 200 OK
< Server: CouchDB/1.3.0a-b9af7ea-git (Erlang OTP/R15B02)
< ETag: "9-4310e4b1fcab6822344790d37fb5ddea"
< Date: Wed, 14 Nov 2012 18:04:57 GMT
< Content-Type: multipart/related; boundary="a38b2d614bb2a8d70e31050a0e2e11a5"
< Content-Length: 493
<
--a38b2d614bb2a8d70e31050a0e2e11a5
content-type: application/json
{"_id":"asd","_rev":"9-4310e4b1fcab6822344790d37fb5ddea","foo":"var","_attachments":{"test.txt":{"content_type":"text/plain","revpos":8,"digest":"md5-7xbQv30HNBSgLpMDsQTH7A==","length":12,"follows":true,"encoding":"gzip","encoded_length":30}}}
--a38b2d614bb2a8d70e31050a0e2e11a5
Content-ID: test.txt
Content-Type: text/plain
Content-Length: 30
Content-Transfer-Encoding: gzip
K??WHJ,?*.?5?
--a38b2
The closing boundary is off, I seem to have a bug in the main request’s
Content-Length calculation, but this is the direction this is going.
> multipart/related document body doesn't identify which part is which
> attachment
> -------------------------------------------------------------------------------
>
> Key: COUCHDB-1368
> URL: https://issues.apache.org/jira/browse/COUCHDB-1368
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
> Reporter: Jens Alfke
> Priority: Minor
>
> If you GET a document with attachments in multipart/related format (by adding
> ?attachments=true and setting Accept:multipart/related), the MIME bodies for
> the attachments have no headers. This makes it difficult to tell which one is
> which. Damien says they're in the same order that they appear in the
> document's "_attachments" object ... which is fine if you're Erlang, because
> Erlang preserves the order of keys in a JSON object, but no other JSON
> implementation I know of does that (because they use hashtables instead of
> linked lists.)
> The upshot is that any non-Erlang code trying to parse such a response will
> have to do some by-hand parsing of the JSON data to get the _attachment keys
> in order.
> This can be fixed by adding a "Content-ID" header to each attachment body,
> whose value is the filename. It would be nice if other standard headers were
> added too, like "Content-Type", "Content-Length", "Content-Encoding", as this
> would make it work better with existing MIME multipart libraries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
