On Aug 3, 2012, at 10:36 AM, Paul Davis <[email protected]> wrote:
> I think it was when CouchDB > receives an attachment that's gzipped it doesn't bother doing an > "gunzip > /dev/null" type operation to get the identity length and > then when it sends the attachment to something that doesn't understand > gzip compression there's a mismatch in what lengths are expected. Thanks for the info — this is relevant to my interests. When TouchDB PUTs a gzipped attachment body it marks it as encoded in the JSON _attachments dict; so CouchDB shouldn't be needing to decompress it right then, since it can store it in the gzipped form (unless it wants to validate the data integrity first?) Also, the Content-Length of the attachment MIME body is the gzipped length, not the uncompressed length. > Or something along those lines. Anyone got a bug number I could look at? I'd really appreciate it! —Jens
