[
https://issues.apache.org/jira/browse/COUCHDB-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778449#action_12778449
]
Paul Joseph Davis commented on COUCHDB-558:
-------------------------------------------
Filipe,
decode_packet looks like it's what we want. But I'd have to play with it some
to see for certain.
Also, sorry to not mention this earlier, but attachments already calculate
their MD5 as they're streamed to disk. Every MD5 implementation I've ever seen
has an incremental implementation with a one call shortcut. Hashing algorithms
like these are generally designed for exactly this reason of avoiding an entire
copy of the dataset in RAM.
The temp file solution is far too complex, but we already have access to a
computed MD5 so it shouldn't be necessary. All that should be necessary is
adding the code to parse out footers when they're reached.
> Validate Content-MD5 request headers on uploads
> -----------------------------------------------
>
> Key: COUCHDB-558
> URL: https://issues.apache.org/jira/browse/COUCHDB-558
> Project: CouchDB
> Issue Type: Improvement
> Components: Database Core, HTTP Interface
> Reporter: Adam Kocoloski
> Fix For: 0.11
>
> Attachments: jira-couchdb-558-for-trunk-2nd-try.patch,
> jira-couchdb-558-for-trunk-3rd-try.patch, jira-couchdb-558-for-trunk.patch,
> run.tpl.patch
>
>
> We could detect in-flight data corruption if a client sends a Content-MD5
> header along with the data and Couch validates the MD5 on arrival.
> RFC1864 - The Content-MD5 Header Field
> http://www.faqs.org/rfcs/rfc1864.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
