[jira] [Commented] (COUCHDB-687) Add md5 hash to _attachments properties for documents
[
https://issues.apache.org/jira/browse/COUCHDB-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13037297#comment-13037297
]
Filipe Manana commented on COUCHDB-687:
---
Randall, that seems a whole new problem that was not in the original scope of
this ticket. I would suggest moving it into another ticket. Also, there's an
?att_encoding_info=true parameter which gives information about attachment
encoding.
Let's just stick to the original goal of exposing the md5 digest of an
attachment in its identity form.
Add md5 hash to _attachments properties for documents
-
Key: COUCHDB-687
URL: https://issues.apache.org/jira/browse/COUCHDB-687
Project: CouchDB
Issue Type: Improvement
Environment: CouchDB
Reporter: mikeal
Assignee: Filipe Manana
Attachments: couchdb-md5-in-attachment-COUCHDB-687-v2.patch,
couchdb-md5-in-attachment-COUCHDB-687-v3.patch,
couchdb-md5-in-attachment-COUCHDB-687.patch, md5.patch
The current attachment information looks like this:
GET /dbname/docid
_attachments: {
jquery-1.4.1.min.js: {
content_type: text/javascript
revpos: 138
length: 70844
stub: true
}
}
If a client wanted to sync local files as attachments with a document it
would not currently be able to do so without keeping a local store of the
revpos. If this information included an md5 hash of the attachment clients
could compare it against a hash of the local file to see if they match.
-Mikeal
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-687) Add md5 hash to _attachments properties for documents
[
https://issues.apache.org/jira/browse/COUCHDB-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13037300#comment-13037300
]
Robert Newson commented on COUCHDB-687:
---
+1 on reporting the md5 we've calculated for this ticket. Showing the other
md5, if its different, is a new ticket (and one I'm not that keen on).
This strikes me as very wrong;
CouchDB needs to be transparent in how it's creating revision identifiers.
I prefer;
CouchDB needs to be completely opaque in how it's creating revision
identifiers.
:)
Add md5 hash to _attachments properties for documents
-
Key: COUCHDB-687
URL: https://issues.apache.org/jira/browse/COUCHDB-687
Project: CouchDB
Issue Type: Improvement
Environment: CouchDB
Reporter: mikeal
Assignee: Filipe Manana
Attachments: couchdb-md5-in-attachment-COUCHDB-687-v2.patch,
couchdb-md5-in-attachment-COUCHDB-687-v3.patch,
couchdb-md5-in-attachment-COUCHDB-687.patch, md5.patch
The current attachment information looks like this:
GET /dbname/docid
_attachments: {
jquery-1.4.1.min.js: {
content_type: text/javascript
revpos: 138
length: 70844
stub: true
}
}
If a client wanted to sync local files as attachments with a document it
would not currently be able to do so without keeping a local store of the
revpos. If this information included an md5 hash of the attachment clients
could compare it against a hash of the local file to see if they match.
-Mikeal
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1173) Verify MD5 when replicating attachments
Verify MD5 when replicating attachments --- Key: COUCHDB-1173 URL: https://issues.apache.org/jira/browse/COUCHDB-1173 Project: CouchDB Issue Type: Improvement Affects Versions: 1.0.2 Reporter: Robert Newson Assignee: Robert Newson Apparently we don't currently verify the MD5 of attachments when we replicate them. So do that. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1174) Multipart parsing bug in new replicator
Multipart parsing bug in new replicator --- Key: COUCHDB-1174 URL: https://issues.apache.org/jira/browse/COUCHDB-1174 Project: CouchDB Issue Type: Bug Affects Versions: 1.2 Reporter: Robert Newson It seems the new multipart savvy replicator has a bug. At high load, the receiving node sees the following as the method of a new http request; --17481297448f5a282cc919203957ebd9--POST instead of just POST. The first bit looks like a multipart boundary value to me. I'll attach a script that reproduces the error now. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1174) Multipart parsing bug in new replicator
[ https://issues.apache.org/jira/browse/COUCHDB-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson updated COUCHDB-1174: --- Attachment: COUCHDB-1174.sh This script * induces method_not_allowed bug on trunk * induces a function_clause in write_streamed_attachment in 1.0.2 and 1.0.x Multipart parsing bug in new replicator --- Key: COUCHDB-1174 URL: https://issues.apache.org/jira/browse/COUCHDB-1174 Project: CouchDB Issue Type: Bug Affects Versions: 1.2 Reporter: Robert Newson Attachments: COUCHDB-1174.sh It seems the new multipart savvy replicator has a bug. At high load, the receiving node sees the following as the method of a new http request; --17481297448f5a282cc919203957ebd9--POST instead of just POST. The first bit looks like a multipart boundary value to me. I'll attach a script that reproduces the error now. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1174) Multipart parsing bug in new replicator
[ https://issues.apache.org/jira/browse/COUCHDB-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson updated COUCHDB-1174: --- Priority: Blocker (was: Major) Filipe speculates its an unterminated chunked transfer encoding; it's missing the final 0 byte chunk for eof. The end of multipart marker is present but runs directly into the next request. Multipart parsing bug in new replicator --- Key: COUCHDB-1174 URL: https://issues.apache.org/jira/browse/COUCHDB-1174 Project: CouchDB Issue Type: Bug Affects Versions: 1.2 Reporter: Robert Newson Priority: Blocker Attachments: COUCHDB-1174.sh It seems the new multipart savvy replicator has a bug. At high load, the receiving node sees the following as the method of a new http request; --17481297448f5a282cc919203957ebd9--POST instead of just POST. The first bit looks like a multipart boundary value to me. I'll attach a script that reproduces the error now. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r1125654 - in /couchdb/trunk: AUTHORS THANKS
Woot! On May 21, 2011, at 5:47 AM, rand...@apache.org wrote: Author: randall Date: Sat May 21 09:47:32 2011 New Revision: 1125654 URL: http://svn.apache.org/viewvc?rev=1125654view=rev Log: moving myself from THANKS to AUTHORS Modified: couchdb/trunk/AUTHORS couchdb/trunk/THANKS Modified: couchdb/trunk/AUTHORS URL: http://svn.apache.org/viewvc/couchdb/trunk/AUTHORS?rev=1125654r1=1125653r2=1125654view=diff == --- couchdb/trunk/AUTHORS (original) +++ couchdb/trunk/AUTHORS Sat May 21 09:47:32 2011 @@ -16,5 +16,6 @@ documentation or developing software. So * Benoît Chesneau beno...@apache.org * Filipe Manana fdman...@apache.org * Robert Newson rnew...@apache.org + * Randall Leeds rand...@apache.org For a list of other credits see the `THANKS` file. Modified: couchdb/trunk/THANKS URL: http://svn.apache.org/viewvc/couchdb/trunk/THANKS?rev=1125654r1=1125653r2=1125654view=diff == --- couchdb/trunk/THANKS (original) +++ couchdb/trunk/THANKS Sat May 21 09:47:32 2011 @@ -48,7 +48,6 @@ suggesting improvements or submitting ch * Joel Clark unsigned_c...@yahoo.com * Matt Lyon m...@flowerpowered.com * mikeal mikeal.rog...@gmail.com - * Randall Leeds randall.le...@gmail.com * Joscha Feth jos...@feth.com * Jarrod Roberson jar...@vertigrated.com * Jae Kwon jkwon.w...@gmail.com
