Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of fdmanana@gmail.com designates
 209.85.220.209 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:reply-to:in-reply-to:references:date:message-id
         :subject:from:to:content-type;
        b=GE1QgFXQtctpQZ1d2ng5ogY3KhRa5rQ6dC5Qhzu85ZWpKx7L4d9LM7aQad8XFjtQuY
         sTrYgLwv/TW6b8KY0es4qMzRrdfod4W75qkCvQYLrGBcrfOyEk0Ld18t1og00lOR2I2j
         X6/9ejfbc40/SDmzlpecdYxOHdtPlaPG+iToQ=
MIME-Version: 1.0
Reply-To: fdmanana@gmail.com
In-Reply-To: <20100323090513.GA5628@uk.tiscali.com>
References: <20100317204512.GA15930@uk.tiscali.com>
	 <20100317215320.GA16659@uk.tiscali.com>
	 <e2111bbb1003171523o4f7fb8b4pbca885a752de8dc1@mail.gmail.com>
	 <560F52C4-A702-466F-9A7B-227FB3B81C0D@merrells.com>
	 <e2111bbb1003171538w27956d12g81647590cd100503@mail.gmail.com>
	 <7D81536C-491E-47FC-A2A0-BFEB2E3020B7@merrells.com>
	 <ec7a93a1003171552l682d7952v2e4ac6b8c74c9106@mail.gmail.com>
	 <20100318121929.GA6866@uk.tiscali.com>
	 <cadf1c691003221709w606fa354o5efa18ccad186f08@mail.gmail.com>
	 <20100323090513.GA5628@uk.tiscali.com>
Date: Tue, 23 Mar 2010 11:53:38 +0000
Message-ID: <cadf1c691003230453m5a20c391s6ebb3e9d94d94db3@mail.gmail.com>
Subject: Re: standalone attachments and content-encoding header
From: Filipe David Manana <fdmanana@gmail.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=00151747b0b8dbe1cc048276767e

--00151747b0b8dbe1cc048276767e
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 23, 2010 at 9:05 AM, Brian Candler <B.Candler@pobox.com> 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,
fdmanana@gmail.com

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

--00151747b0b8dbe1cc048276767e--