Jens Alfke created COUCHDB-1521:
-----------------------------------

             Summary: multipart parser gets multiple attachments mixed up
                 Key: COUCHDB-1521
                 URL: https://issues.apache.org/jira/browse/COUCHDB-1521
             Project: CouchDB
          Issue Type: Bug
          Components: HTTP Interface
    Affects Versions: 1.2
            Reporter: Jens Alfke


When receiving a document PUT in multipart format, CouchDB gets the attachments 
and MIME parts mixed up. Instead of looking at the headers of a MIME part to 
identify which attachment it is (most likely by using the 'filename' property 
of the 'Content-Disposition:' header), it processes the attachments according 
to the order in which their metadata objects appear in the JSON body's 
'_attachments:' object.

The problem with this is that JSON objects (dictionaries) are _not_ ordered 
collections. I know that Erlang's implementation of them (as linked lists of 
key/value pairs) happens to be ordered, and I think some JavaScript 
implementations have the side effect of preserving order; but in many languages 
these are implemented as hash tables and genuinely unordered.

This means that when a program written in such a language converts a native 
object to JSON, it has no control over (and probably no knowledge of) the order 
in which the keys of the JSON object are written out. This makes it impossible 
to then write the attachments in the same order.

The only workaround seems to be for the program to implement its own custom 
JSON encoder just so that it can write object keys in a known order (probably 
sorted), which then enables it to write the attachment bodies in the same order.

NOTE: This is the flip side of COUCHDB-1368 which I filed last year; that bug 
has to do with the same ordering issue when CouchDB _generates_ multipart 
responses (and presents similar problems for clients not written in Erlang.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to