[ https://issues.apache.org/jira/browse/COUCHDB-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497240#comment-13497240 ]
Jens Alfke commented on COUCHDB-1368: ------------------------------------- Where is the branch? I don't see it in the github UI at https://github.com/apache/couchdb . Also, could you post a sample of what the MIME headers look like for an attachment part? > 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