[ https://issues.apache.org/jira/browse/COUCHDB-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Filipe Manana updated COUCHDB-583: ---------------------------------- Attachment: couchdb-583-trunk-9th-try.patch 9th patch + simplified code in couch_httpd_db.erl (nested case expressions), thanks davidc_ for pointing the mess + gracefully merges with trunk svn rev 898552 > storing attachments in compressed form and serving them in compressed form if > accepted by the client > ---------------------------------------------------------------------------------------------------- > > Key: COUCHDB-583 > URL: https://issues.apache.org/jira/browse/COUCHDB-583 > Project: CouchDB > Issue Type: New Feature > Components: Database Core, HTTP Interface > Environment: CouchDB trunk > Reporter: Filipe Manana > Attachments: couchdb-583-trunk-3rd-try.patch, > couchdb-583-trunk-4th-try-trunk.patch, couchdb-583-trunk-5th-try.patch, > couchdb-583-trunk-6th-try.patch, couchdb-583-trunk-7th-try.patch, > couchdb-583-trunk-8th-try.patch, couchdb-583-trunk-9th-try.patch, > jira-couchdb-583-1st-try-trunk.patch, jira-couchdb-583-2nd-try-trunk.patch > > > This feature allows Couch to gzip compress attachments as they are being > received and store them in compressed form. > When a client asks for downloading an attachment (e.g. GET > somedb/somedoc/attachment.txt), the attachment is sent in compressed form if > the client's http request has gzip specified as a valid transfer encoding for > the response (using the http header "Accept-Encoding"). Otherwise couch > decompresses the attachment before sending it back to the client. > Attachments are compressed only if their MIME type matches one of those > listed in a separate config file. Compression level is also configurable in > the default.ini file. > This follows Damien's suggestion from 30 November: > "Perhaps we need a separate user editable ini file to specify compressable or > non-compressable files (would probably be too big for the regular ini file). > What do other web servers do? > Also, a potential optimization is to compress the file while writing to disk, > and serve the compressed bytes directly to clients that can handle it, and > decompressed for those that can't. For compressable types, it's a win for > both disk IO for reads and writes, and CPU on read." > Patch attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.