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: 1.0.1, 1.0, 0.11.2, 0.11.1, 0.11
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.
