[
https://issues.apache.org/jira/browse/COUCHDB-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778587#action_12778587
]
Filipe Manana commented on COUCHDB-558:
---------------------------------------
Definitely, erlang:decode_packet/3 works fine, so now the trailer function is:
%% @spec to_mochiweb_headers([binary()]) -> headers()
%%
%% Transforms the given binary list into a Mochiweb
%% headers structure. Each binary is a raw HTTP header
%% line (e.g. <<"Content-Lengh: 345\r\n">>).
%%
to_mochiweb_headers(BinaryList) ->
F = fun(Bin, Acc) ->
{ ok, {http_header, _, H, _, V}, _ } =
erlang:decode_packet(httph, list_to_binary([Bin,"\r\n"]), []),
[ {H, V} | Acc ]
end,
mochiweb_headers:make(lists:foldr(F, [], BinaryList)).
Works fine as long as mochiweb returns the trailer as a list of binaries having
the format <<"Header: value\r\n">>.
Hum, I was not aware that the attachment handling code already calculate MD5
digests and neither that it was possible to calculate MD5 digests incrementally
I am looking into couch_db.erl, flush_att() function, where the trailer (named
footer there) is ignored. I'll take some time to have a good understanding of
how the doc attachment works. This is a completely unfamiliar territory for me.
I see that whenever a chunk is received, it is immediately written to an output
stream, and an incremental MD5 is calculated. Is this MD5 currently used for
something?
When receiving the trailer, if it contains a Content-MD5 header and the value
doesn't match the one calculated by couchdb, what would be the action to take?
Just report an error? Or something more radical like deleting the attachment or
mark it as corrupted?
Thanks for the tip.
best regards
> 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.
