incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Merrells <>
Subject Re: standalone attachments and content-encoding header
Date Wed, 17 Mar 2010 20:53:57 GMT

On Mar 17, 2010, at 1:45 PM, Brian Candler wrote:

> 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?

* About to connect() to port 5984 (#0)
*   Trying connected
* Connected to ( port 5984 (#0)
* Server auth using Basic with user 'admin'
> GET /pages/ HTTP/1.1
> Authorization: Basic YWRtaW46Y2FtbWF4em9l
> User-Agent: curl/7.19.6 (i386-apple-darwin10.0.0) libcurl/7.19.6 zlib/1.2.3
> Host:
> Accept: */*
> Accept-Encoding: deflate, gzip
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: CouchDB/0.10.1 (Erlang OTP/R13B)
Server: CouchDB/0.10.1 (Erlang OTP/R13B)
< ETag: "2-1d1c512ddcf00a7d8b1a7f8052f06314"
ETag: "2-1d1c512ddcf00a7d8b1a7f8052f06314"
< Date: Wed, 17 Mar 2010 20:46:51 GMT
Date: Wed, 17 Mar 2010 20:46:51 GMT
< Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
< Content-Length: 19909
Content-Length: 19909
< Cache-Control: must-revalidate
Cache-Control: must-revalidate

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

It's not json :-)

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

From what Futon reports it doesn't appear that way.

But I want to also be sending compressed data, not having couch do the 

>> 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?



Some pseudo ruby 

        attachement= Zlib::Deflate.deflate("some html text")
        headers= {'content-encoding'=>'deflate',:content_type=>'text/html'}

Now point your browser at the url for that attachment and a blob is displayed rather than
decompressed and displayed.


John Merrells

View raw message