[
https://issues.apache.org/jira/browse/COUCHDB-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980655#action_12980655
]
Robert Newson commented on COUCHDB-1022:
----------------------------------------
I added a guard clause to write_streamed_attachment so we blow up earlier. This
seemed simpler than adding a clause that just throws, which felt quite
unidiomatic. The main clause is now explicit about its expectative of positive
valence on LenLeft.
-write_streamed_attachment(Stream, F, LenLeft) ->
+write_streamed_attachment(Stream, F, LenLeft) when LenLeft > 0 ->
Sadly I referenced COUCHDB-1021 and not 1022 in the commit msg :(
> Doc GET multipart/related and multipart/mixed APIs with wrong lengths in
> attachment stubs
> -----------------------------------------------------------------------------------------
>
> Key: COUCHDB-1022
> URL: https://issues.apache.org/jira/browse/COUCHDB-1022
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core, HTTP Interface
> Affects Versions: 0.11, 0.11.1, 0.11.2, 1.0, 1.0.1
> Environment: all
> Reporter: Filipe Manana
> Assignee: Filipe Manana
> Fix For: 0.11.3, 1.0.2, 1.1
>
> Attachments: multipart_1_0_x.patch
>
>
> Up to 1.0.1, it was possible to loose the identity length of an attachment
> that was compressed by CouchDB. The only case known where this happened was
> after doing a local to local replication. This was found and fixed recently
> in 1.0.x with a patch from Juuso Väänänen, COUCHDB-930.
> However, existing databases created with versions up to 1.0.1, have the
> attachment identify length lost forever. For this cases, the
> multipart/related or multipart/mixed APIs used to GET a document, return
> attachments stubs with a "length" field matching the length of the attachment
> in compressed form, and the part of the multipart stream that contains the
> attachment, contains it in uncompressed form.
> This poses a serious problem to the CouchDB multipart parser, an essential
> part used by the new replicator that's likely to land on the 1.2 release.
> Without this fix, it may not be possible to do pull replications, with the
> new replicator, from versions 0.11.0, 0.11.1, 0.11.2, 1.0.0 and 1.0.1 ONLY
> when the source database was the product of a local to local replication (and
> there are attachments stored in compressed form, as described by COUCHDB-930).
> The following patch fixes this issue by always sending the attachments in
> compressed form. It's meant to be applied against branches 0.11.x, 1.0.x,
> 1.1.x and trunk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
