On Tue, Mar 23, 2010 at 9:05 AM, Brian Candler <[email protected]> wrote:
> 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? > True. I guess I shouldn't reply anymore during late evening :) The problem I see here is that not supplying, in an attachment stub, the length of the attachment in uncompressed form breaks the existing API. Currently the "length" field of an attachment stub is always the length of the attachment in its identity (uncompressed) form. If you upload attachment A in uncompressed form, the "length" field in the attachment stub will match the length of the attachment in uncompressed form. On the other hand, if you upload that same attachment in compressed form, that "length" field will match the length of the attachment in compressed form. Uncompressing the attachment just to calculate its identity length seems a bit heavy, no? -- Filipe David Manana, [email protected] "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
