You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Filipe Manana (JIRA)" <ji...@apache.org> on 2011/01/11 20:28:46 UTC
[jira] Created: (COUCHDB-1022) Doc GET multipart/related and
multipart/mixed APIs with wrong lengths in attachment stubs
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.
[jira] Updated: (COUCHDB-1022) Doc GET multipart/related and
multipart/mixed APIs with wrong lengths in attachment stubs
Posted by "Filipe Manana (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Filipe Manana updated COUCHDB-1022:
-----------------------------------
Attachment: multipart_1_0_x.patch
> 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.
[jira] Closed: (COUCHDB-1022) Doc GET multipart/related and
multipart/mixed APIs with wrong lengths in attachment stubs
Posted by "Filipe Manana (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Filipe Manana closed COUCHDB-1022.
----------------------------------
Resolution: Fixed
Patch applied to all the branches mentioned in the description.
> 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.
[jira] Commented: (COUCHDB-1022) Doc GET multipart/related and
multipart/mixed APIs with wrong lengths in attachment stubs
Posted by "Filipe Manana (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980661#action_12980661 ]
Filipe Manana commented on COUCHDB-1022:
----------------------------------------
Robert, perfectly fine, simpler than explicitly throwing an exception when LenLeft < 0.
thanks
> 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.
[jira] Commented: (COUCHDB-1022) Doc GET multipart/related and
multipart/mixed APIs with wrong lengths in attachment stubs
Posted by "Robert Newson (JIRA)" <ji...@apache.org>.
[ 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.