incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filipe David Manana <fdman...@gmail.com>
Subject Re: standalone attachments and content-encoding header
Date Tue, 23 Mar 2010 00:09:44 GMT
On Thu, Mar 18, 2010 at 12:19 PM, Brian Candler <B.Candler@pobox.com> wrote:

> On Wed, Mar 17, 2010 at 03:52:36PM -0700, Randall Leeds wrote:
> > It seems like couch should probably store content-encoding as metadata
> > on the attachment (like content-type) and pass these attachments
> > straight to disk and serve them up with the appropriate
> > content-encoding
>
> What happens if another client requests the same document but doesn't
> understand that particular Content-Encoding?  Couchdb would then have to
> refuse to *serve* the document out to the second client, if its
> Accept-Encoding: list didn't include the encoding stored to disk.
>

> Or couchdb would have to transcode on demand, potentially twice:
> deflate->identity->gzip for example.
>

Somehow I feel that transcoding is a bit unnatural and consumes too much cpu
for large attachments.


> > OR reject the original upload as unsupported.
>

This would definitely be the simplest approach, by accepting only the "gzip"
content encoding.

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).

Also, supporting multiple content-encodings would imply doing some changes
to the code introduced in ticket 639 (applied to trunk only) which adds a
new doc query parameter ?att_gzip_length=true. (replacing it with 2
parameters such as encoding=<encoding_name> and encoded_length=123).

I am more inclined for supporting only the gzip encoding for attachments,
but this should be a community decision, therefore I include this reply to
the dev mailing list.


> I think it should do this anyway for JSON document bodies. Couchdb
> shouldn't
> attempt to JSON-parse the body if it has come in using an encoding that it
> doesn't understand.
>



-- 
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."

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