If the attachment request doesn't have "Accept-Encoding: deflate", then couch needs to know the attachment is deflate compressed and uncompress the attachment before sending it to the client. A missing Accept-Encoding header is the same as "Accept-Encoding: identity, *;q=0". Therefore you need to know the attachment was uploaded with deflate encoding and how to uncompress it. On Wed, Mar 17, 2010 at 10:49 PM, John Merrells wrote: > > On Mar 17, 2010, at 3:38 PM, Paul Davis wrote: > > > That's not how HTTP works though. For it to respond with a > > "Content-Encoding: deflate" header CouchDB would need to understand > > the deflate content type and you would have to specify an > > Accept-Encoding header that preferred deflate over everything else. > > > > Patching in deflate support is a-ok by me if someone wants to do that. > > But just echoing headers isn't a viable solution. > > Just as couch doesn't need to know about a content-type in order to > serve content of that type, it also doesn't need to know about its > encoding, > if the content is already encoded in that way. If the UA asked for a > different > encoding than that which the content was in, then sure that's a problem, > but that's not the case here. > > So the client sends.... > > UA ---> Couch > PUT /database/document_id/attachment_name > content-type: foo/baz > content-encoding: bar > > And so when the client asks for its blob back > > UA ---> Couch > GET /database/document_id/attachment_name > accept-encoding: bar > > We would expect... > > Couch <--- UA > content-type: foo/baz > content-encoding: bar > > But this is actually what is returned... > > Couch <--- UA > content-type: foo/baz > > So, it dropped the encoding, which is confusing for the client. > > John > > -- > John Merrells > http://johnmerrells.com > +1.415.244.5808 > > > > > > > -- 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."