On Wed, Mar 17, 2010 at 6:52 PM, 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 OR reject the original upload as unsupported. > > I agree that the current situation is wrong. I think in the current situation we're wrong. But to fix the current situation we either need to reject content-encodings we don't know about or add the code to deal with them. Whether the implementation goes on and stores attachments in the encoding in which they were uploaded is an implementation detail. Though, it could get interesting when someone stores a deflate attachment and wants to retrieve it as gzip. Either way, CouchDB not being able to server and identity encoded body of an attachment seems like a very silly proposition. Paul > On Wed, Mar 17, 2010 at 15:49, 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 >> >> >> >> >> >> >> >