Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 51582 invoked from network); 20 Dec 2009 10:54:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 20 Dec 2009 10:54:47 -0000 Received: (qmail 60855 invoked by uid 500); 20 Dec 2009 10:54:46 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 60771 invoked by uid 500); 20 Dec 2009 10:54:45 -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 60761 invoked by uid 99); 20 Dec 2009 10:54:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 20 Dec 2009 10:54:45 +0000 X-ASF-Spam-Status: No, hits=-10.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,WEIRD_PORT 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; Sun, 20 Dec 2009 10:54:38 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 25FA2234C045 for ; Sun, 20 Dec 2009 02:54:18 -0800 (PST) Message-ID: <14276723.1261306458140.JavaMail.jira@brutus> Date: Sun, 20 Dec 2009 10:54:18 +0000 (UTC) From: "Filipe Manana (JIRA)" To: dev@couchdb.apache.org Subject: [jira] Updated: (COUCHDB-583) adding ?compression=(gzip|deflate) optional parameter to the attachment download API 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:all-tabpanel ] Filipe Manana updated COUCHDB-583: ---------------------------------- Attachment: couchdb-583-trunk-4th-try-trunk.patch Here follows an updated patch. relatively to the previous one: + works with ticket 558 (attachment upload md5 integrity check) + adds gzip compression level configuration option + no longer breaks 2 Etap tests and 2 JavaScript tests :) All tests, except for the Etap ICU test (which is broken for some other reason), are working with this patch. Etap test included for the new feature is included. The feature of this patch seems to be the same that is requested in ticket 437 => https://issues.apache.org/jira/browse/COUCHDB-437 Feedback please cheers > adding ?compression=(gzip|deflate) optional parameter to the attachment download API > ------------------------------------------------------------------------------------ > > Key: COUCHDB-583 > URL: https://issues.apache.org/jira/browse/COUCHDB-583 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface > Environment: CouchDB trunk revision 885240 > Reporter: Filipe Manana > Attachments: couchdb-583-trunk-3rd-try.patch, couchdb-583-trunk-4th-try-trunk.patch, jira-couchdb-583-1st-try-trunk.patch, jira-couchdb-583-2nd-try-trunk.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > The following new feature is added in the patch following this ticket creation. > A new optional http query parameter "compression" is added to the attachments API. > This parameter can have one of the values: "gzip" or "deflate". > When asking for an attachment (GET http request), if the query parameter "compression" is found, CouchDB will send the attachment compressed to the client (and sets the header Content-Encoding with gzip or deflate). > Further, it adds a new config option "treshold_for_chunking_comp_responses" (httpd section) that specifies an attachment length threshold. If an attachment has a length >= than this threshold, the http response will be chunked (besides compressed). > Note that using non chunked compressed body responses requires storing all the compressed blocks in memory and then sending each one to the client. This is a necessary "evil", as we only know the length of the compressed body after compressing all the body, and we need to set the "Content-Length" header for non chunked responses. By sending chunked responses, we can send each compressed block immediately, without accumulating all of them in memory. > Examples: > $ curl http://localhost:5984/testdb/testdoc1/readme.txt?compression=gzip > $ curl http://localhost:5984/testdb/testdoc1/readme.txt?compression=deflate > $ curl http://localhost:5984/testdb/testdoc1/readme.txt # attachment will not be compressed > $ curl http://localhost:5984/testdb/testdoc1/readme.txt?compression=rar # will give a 500 error code > Etap test case included. > Feedback would be very welcome. > cheers -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.