couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: standalone attachments and content-encoding header
Date Wed, 17 Mar 2010 20:45:12 GMT
On Wed, Mar 17, 2010 at 01:32:24PM -0700, John Merrells wrote:
> I'll give it a go...

Can you add -v to that too?

> I'm not asking couch to compress the content before sending it, as I compressed
> it before I pushed it up. All I want is for couch to send me back that content-encoded

> header that I sent up with it....

I don't think it's that simple. For docs, couchdb has to parse the JSON you
send it (to turn it it into erlang terms), so it has to uncompress it
anyway.

As for attachments, I'm not sure but I *believe* they're always stored
compressed.  I remember seeing some optimisation work in progress, so that
if the client sends a compressed attachment it would be saved as-is rather
than decompressed and recompressed - or something like that.

> then the user agent will do the right thing when it
> resolve the attachment url into couch.... right now the browser gets text/html and
> a bunch of binary... if it had content-encoded then it'd know to decompress it before
> displaying it....

Ah, then I've missed the point. Are you saying that you're storing an
attachment with Encoding: gzip, and couchdb is returning the gzipped binary
blob but without an Encoding: gzip header?  Perhaps there's a bug.  What
version of couchdb? Have you got a simple test case to reproduce it?

Regards,

Brian.

Mime
View raw message