Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Tue, 7 May 2013 21:41:16 +0000 (UTC)
From: "Christopher Bonhage (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12535928.1324424666916.283839.1367962876450@arcas>
In-Reply-To: <JIRA.12535928.1324424666916@arcas>
References: <JIRA.12535928.1324424666916@arcas>
Subject: [jira] [Commented] (COUCHDB-1368) multipart/related document body
 doesn't identify which part is which attachment
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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