[
https://issues.apache.org/jira/browse/COUCHDB-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Bonhage updated COUCHDB-1368:
-----------------------------------------
Attachment: replication.log
Attached is the debug log from my 1.3.0 CouchDB pushing from database 'wtf' to
database 'wtf2' over HTTP (127.0.0.1).
The smaller docs are 'PUT' into wtf2 as multipart just fine. The 'oldui' doc
has 96 attachments and goes through, but the 'newui' doc has 587 attachments
and causes the error loop. From this point, the database starts to balloon in
size until the couch is killed or disk space is exhausted.
I can also confirm that this issue does not occur with the multipart header
patches mentioned above are applied.
> 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
> Attachments: replication.log
>
>
> 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
