[
https://issues.apache.org/jira/browse/COUCHDB-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana updated COUCHDB-558:
----------------------------------
Attachment: run.tpl.patch
Thanks again for your feedback and point of view Paul,
regarding the remark:
"The to_mochiweb_headers should probably use an existing mochiweb function for
header parsing so that we can blame someone when its not right. I'm pretty sure
that regexp would break with white space left of the colon and leaves
whitespace after the value."
Well, mochiweb obtains an header's name and value directly from a call to
gen_tcp:recv() for a socket configured with:
inet:setopts(Socket, [{packet, http}]) (mochiweb_http.erl)
Example in mochiweb_http.erl:
case gen_tcp:recv(Socket, 0, ?IDLE_TIMEOUT) of
{ok, {http_header, _, Name, _, Value}} ->
headers(Socket, Request, [{Name, Value} | Headers], Body,
1 + HeaderCount);
I couldn't find any function in mochiweb for parsing an header's name and value
from a raw http header line string/binary :(
In the meanwhile I'am improving my regex to something like:
"^\s*(.*?)\s*:\s*(.*?)\s*\r\n$"
I haven't looked yet into the source code of gen_tcp:recv().. Maybe there's a
regex there I can take :)
Yes, this RAM buffering might be problematic. With the statement "This means
delaying md5 on chunked transfers until the trailers are read", what do you
mean exactly? That instead of buffering in couch_httpd, to do the buffering in
mochiweb's code? If so, is it only for a better design cause or do you have
something else in mind?
Also, while I am looking into how to write the Erlang tests with ETAP, I found
a small issue with test/etap/run.tpl.
The attached patch fixes the problem.
cheers
> 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.
