[
https://issues.apache.org/jira/browse/COUCHDB-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651339#comment-13651339
]
Christopher Bonhage commented on COUCHDB-1368:
----------------------------------------------
Hi Robert, I most definitely can reproduce this between two 1.3.0 Couches.
When attempting to push replicate a database that contains a document with 587
attachments of varying sizes my logs are filled with:
[Tue, 07 May 2013 16:34:11 GMT] [error] [emulator] Error in process <0.3217.0>
with exit value:
{{badmatch,{[137,80,78,71],[]}},[{couch_httpd,split_header,1,[{file,"couch_httpd.erl"},{line,1014}]},{couch_httpd,'-parse_part_header/1-fun-1-',2,[{file,"couch_httpd.erl"},{line,1057}]},{lists,foldl,3,[{file,"lists.erl"},{line,1197}]},{couch_httpd,parse_part_header...
> 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