incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Bonhage (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1368) multipart/related document body doesn't identify which part is which attachment
Date Tue, 07 May 2013 21:21:16 GMT

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

Christopher Bonhage commented on COUCHDB-1368:
----------------------------------------------

I just got burned by this on 1.3.0 when my replicator tried to send a doc with a large number
of attachments as multipart. The receiving couch (also running 1.3.0) went into a barf loop
trying to parse the non-existent headers of the multipart request.

Considering how this breaks the replicator and causes CouchDB to fill the disk, this seems
like more than a minor bug.

I highly suggest merging the following commits into the next bugfix for 1.3.x to resolve this
issue:
a2b3cc72229b86805ad11a27e93e74a78d6bdfa6 Send attachment headers in multipart responses
734ca24858c1fdcaa9d998f19bbf7f3e35817f64 fix multipart response mixup, fixes replication.js
                
> 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

Mime
View raw message