Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 1427 invoked from network); 29 Jan 2010 03:55:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 29 Jan 2010 03:55:56 -0000 Received: (qmail 94214 invoked by uid 500); 29 Jan 2010 03:55:56 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 94069 invoked by uid 500); 29 Jan 2010 03:55:55 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 94059 invoked by uid 99); 29 Jan 2010 03:55:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Jan 2010 03:55:55 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Jan 2010 03:55:54 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 8CF88234C48D for ; Thu, 28 Jan 2010 19:55:34 -0800 (PST) Message-ID: <900644821.122191264737334576.JavaMail.jira@brutus.apache.org> Date: Fri, 29 Jan 2010 03:55:34 +0000 (UTC) From: "Chris Anderson (JIRA)" To: dev@couchdb.apache.org Subject: [jira] Commented: (COUCHDB-583) storing attachments in compressed form and serving them in compressed form if accepted by the client In-Reply-To: <844257352.1259509400633.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/COUCHDB-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806217#action_12806217 ] Chris Anderson commented on COUCHDB-583: ---------------------------------------- Looking at Mimeparse and your Mochiweb patches, it looks like you are covering parts of HTTP that Mimeparse doesn't handle yet. So disregard my last comment about using it instead. And I see that the accept stuff is in Mochi also. Rad. So it looks like we can commit this. I'd sure appreciate anyone's help upgrading Mochi from upstream (properly). Filipe, the Mimeparse lib might appreciate your contribution. > 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-10th-try.patch, couchdb-583-trunk-11th-try.patch, couchdb-583-trunk-12th-try.patch, couchdb-583-trunk-13th-try.patch, couchdb-583-trunk-14th-try-git.patch, couchdb-583-trunk-15th-try-git.patch, couchdb-583-trunk-16th-try-git.patch, 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.