I'd like to get to the bottom of that, since it will have negative effects on replication (the md5 of attachments is part of the rev calculation).
Also I noticed that ibrowse master has improved handling of long running requests (e.g, large attachments). Anyone that's seen "streaming att. ended but more data requested ~p" will be interested to know that it appears to eliminate them. B. On 15 January 2012 19:05, Dave Cottlehuber <[email protected]> wrote: > On 15 January 2012 19:05, Noah Slater <[email protected]> wrote: >> Bump. Dave? Gonna move without if you don't speak up. :) > > Sorry!! Literally *just* finished looking at this. > > TL;DR - let's roll 1.2.0. > > I don't see any *functional* issues in the failures from the test > suite - attachments are written, and read, correctly. For some as yet > unknown reason the MD5 is different on Windows vs Linux & Mac OS, but > this has been present for some time. It's only turned up as a result > of additional tests applied in COUCHDB-1337. > > The underlying crypto:md5 values are the same, and so is the raw HTTP > data. I am still digging through mochi to where this comes from. > > I don't see any issues for replication - can anybody confirm? This > looks like a dev issue rather than user impacting. > > from 1.1.1_js-1.8.0: > 12> Digest = base64:encode(Digest_Binary). > <<"jeLnIuUvK7d+6gya044lVA==">> > > from 1.2.x: > 8> Digest = base64:encode(Digest_Binary). > <<"jeLnIuUvK7d+6gya044lVA==">> > > A+ > Dave
