[
https://issues.apache.org/jira/browse/COUCHDB-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778630#action_12778630
]
Paul Joseph Davis commented on COUCHDB-558:
-------------------------------------------
That header parsing makes me feel a lot better. If that decode_packet can take
a whole binary and return a list of headers, we might want to avoid the header
function in mochiweb_multipart.erl as I don't think it was accounting for
multi-line headers which I'm pretty sure are valid.
As to attachment handling, basically if you get to the trailer and the MD5's
don't match, just throw an error when they don't match and let the normal error
handling code take over. Assuming that code works out all right, I think we
could end up just patching mochiweb_request.erl to check MD5's when reading the
body to protect all other handlers.
> 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.
