On Tue, Mar 23, 2010 at 12:09:44AM +0000, Filipe David Manana wrote: > By accepting an already gzip encoded attachment (through the PUT standalone > attachment API) we risk not storing the real length of the attachment > (length of the uncompressed form) in the attachment's metadata, and only the > length of the attachment's encoded form. > That would happen only if the attachment is streamed with a chunked transfer > encoding request (that i.e. no content-length header in the upload request).
I thought content-length referred to the actual number of bytes transferred (i.e. the encoded form), not the original uncompressed object? So to get the "real" size you'd have to decompress anyway?
