np. I think there's a separate ticket for that. 1173 is new and
addresses (my) concerns about attachment replication given some of the
other bugs we see, like the overflow in write_streamed_attachment.

B.

On 26 May 2011 00:32, Randall Leeds <[email protected]> wrote:
> Agreed. Sorry I didn't look carefully enough. I assumed it was in the
> _attachments stub.
>
> On Wed, May 25, 2011 at 16:31, Robert Newson <[email protected]> wrote:
>> The purpose is to ensure the integrity of attachments during
>> replication, it uses a standard header. I don't think it's related to
>> the other conversation about adding md5 to _attachments.
>>
>> B.
>>
>> On 26 May 2011 00:27, Paul Davis <[email protected]> wrote:
>>> On Wed, May 25, 2011 at 7:10 PM, Randall Leeds <[email protected]> 
>>> wrote:
>>>> Should we break this into digest_type and digest so we can change it
>>>> in the future?
>>>>
>>>> On Wed, May 25, 2011 at 15:55,  <[email protected]> wrote:
>>>>> Author: rnewson
>>>>> Date: Wed May 25 22:55:09 2011
>>>>> New Revision: 1127713
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=1127713&view=rev
>>>>> Log:
>>>>> COUCHDB-1173 - return Content-MD5 when fetching attachments where 
>>>>> possible.
>>>>>
>>>>> Modified:
>>>>>    couchdb/trunk/share/www/script/test/attachments.js
>>>>>    couchdb/trunk/src/couchdb/couch_httpd_db.erl
>>>>>
>>>>> Modified: couchdb/trunk/share/www/script/test/attachments.js
>>>>> URL: 
>>>>> http://svn.apache.org/viewvc/couchdb/trunk/share/www/script/test/attachments.js?rev=1127713&r1=1127712&r2=1127713&view=diff
>>>>> ==============================================================================
>>>>> --- couchdb/trunk/share/www/script/test/attachments.js (original)
>>>>> +++ couchdb/trunk/share/www/script/test/attachments.js Wed May 25 
>>>>> 22:55:09 2011
>>>>> @@ -281,4 +281,17 @@ couchTests.attachments= function(debug)
>>>>>   } catch (e) {
>>>>>       T(e.error == "missing_stub");
>>>>>   }
>>>>> +
>>>>> +  // test MD5 header
>>>>> +  var bin_data = "foo bar"
>>>>> +  var xhr = CouchDB.request("PUT", 
>>>>> "/test_suite_db/bin_doc7/attachment.txt", {
>>>>> +    headers:{"Content-Type":"application/octet-stream",
>>>>> +             "Content-MD5":"MntvB0NYESObxH4VRDUycw=="},
>>>>> +    body:bin_data
>>>>> +  });
>>>>> +  TEquals(201, xhr.status);
>>>>> +
>>>>> +  var xhr = CouchDB.request("GET", 
>>>>> "/test_suite_db/bin_doc7/attachment.txt");
>>>>> +  TEquals('MntvB0NYESObxH4VRDUycw==', 
>>>>> xhr.getResponseHeader("Content-MD5"));
>>>>> +
>>>>>  };
>>>>>
>>>>> Modified: couchdb/trunk/src/couchdb/couch_httpd_db.erl
>>>>> URL: 
>>>>> http://svn.apache.org/viewvc/couchdb/trunk/src/couchdb/couch_httpd_db.erl?rev=1127713&r1=1127712&r2=1127713&view=diff
>>>>> ==============================================================================
>>>>> --- couchdb/trunk/src/couchdb/couch_httpd_db.erl (original)
>>>>> +++ couchdb/trunk/src/couchdb/couch_httpd_db.erl Wed May 25 22:55:09 2011
>>>>> @@ -1008,7 +1008,13 @@ db_attachment_req(#httpd{method='GET',mo
>>>>>                         {identity, Ranges} when is_list(Ranges) ->
>>>>>                             send_ranges_multipart(Req, Type, Len, Att, 
>>>>> Ranges);
>>>>>                         _ ->
>>>>> -                            {ok, Resp} = start_response_length(Req, 200, 
>>>>> Headers, Len),
>>>>> +                            Headers1 = Headers ++
>>>>> +                                if Enc =:= identity orelse 
>>>>> ReqAcceptsAttEnc =:= true ->
>>>>> +                                    [{"Content-MD5", 
>>>>> base64:encode(Att#att.md5)}];
>>>>> +                                true ->
>>>>> +                                    []
>>>>> +                            end,
>>>>> +                            {ok, Resp} = start_response_length(Req, 200, 
>>>>> Headers1, Len),
>>>>>                             AttFun(Att, fun(Seg, _) -> send(Resp, Seg) 
>>>>> end, {ok, Resp})
>>>>>                     end
>>>>>                 end
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> Heh. Actually, this is the exact case that I was railing about not
>>> becoming when we discussed signature information in the doc body. Here
>>> though its already been codified by RFC 2616 so breaking it would mean
>>> custom headers.
>>>
>>
>

Reply via email to