couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: function_clause error in HTTP request
Date Wed, 08 Aug 2012 17:39:15 GMT
That's good news, but couchdb should remove this ambiguity. Perhaps the quickest thing is to
add a "follows_order":[] in the json blob which, since the value is an array, can be unambiguously

I'm keener on this idea, though: the JSON blob in a multipart/related PUT does not need to
mention new attachments at all (though it does need stubs to preserve existing attachments).
All non-first parts are explicitly intended to be added to the document. Those parts can have
standard headers that tell us the attachments name and expected length.

The further proposal, mentioned at the Boston Summit, would remove all the magical _-prefix
values from the document, which would motivate us to unpick this tangle even more completely.


On 8 Aug 2012, at 18:26, Jens Alfke wrote:

> Robert,
>> Having read much of the attachment streaming code and the multipart parsing code,
and the manner that they connect, the fix isn't going to be easy but it feels necessary.
>> Each MP part can have http headers, including Content-Length, which points to a way
> Great. Actually the workaround on my side is going to be easier than I thought, because
I just realized I've already written a custom JSON encoder, for the purpose of generating
canonical JSON (necessary for getting consistent revision IDs for the same document bodies.)
And a big part of what that encoder does is write dictionary keys in sorted order. So I can
use that to write the main document body, and then make sure to write the attachment bodies
sorted in the same order by filename. (Pieter, I think I can have this pushed out pretty soon,
probably later today.)
> —Jens

View raw message