couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filipe David Manana <>
Subject Re: standalone attachments and content-encoding header
Date Tue, 23 Mar 2010 11:53:38 GMT
On Tue, Mar 23, 2010 at 9:05 AM, Brian Candler <> 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,

"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message