Return-Path: Delivered-To: apmail-hc-dev-archive@www.apache.org Received: (qmail 574 invoked from network); 6 Aug 2009 14:31:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 6 Aug 2009 14:31:15 -0000 Received: (qmail 64323 invoked by uid 500); 6 Aug 2009 14:19:38 -0000 Delivered-To: apmail-hc-dev-archive@hc.apache.org Received: (qmail 64302 invoked by uid 500); 6 Aug 2009 14:19:38 -0000 Mailing-List: contact dev-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpComponents Project" Delivered-To: mailing list dev@hc.apache.org Received: (qmail 64292 invoked by uid 99); 6 Aug 2009 14:19:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Aug 2009 14:19:37 +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; Thu, 06 Aug 2009 14:19:35 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id C62D0234C044 for ; Thu, 6 Aug 2009 07:19:14 -0700 (PDT) Message-ID: <1778032123.1249568354807.JavaMail.jira@brutus> Date: Thu, 6 Aug 2009 07:19:14 -0700 (PDT) From: "Oleg Kalnichevski (JIRA)" To: dev@hc.apache.org Subject: [jira] Commented: (HTTPCLIENT-834) Transparent Content Coding support In-Reply-To: <1272589212.1237151811067.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HTTPCLIENT-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740078#action_12740078 ] Oleg Kalnichevski commented on HTTPCLIENT-834: ---------------------------------------------- > I hopefully described in the ticket why I think that this should work out of the box without requiring changes for existing clients. > That's why I'm trying to get it working as part of the existing API. Yes, you did, but I still think the chance of breaking existing apps in some subtle ways is simply too high to have this feature enabled per default. > Would people need to alter their code (or maybe just Spring / Guice / etc configuration)? Those who use a DI framework to wire together their components this would be a one liner config change. > Should that be based on trunk or the existing 4.1 branch? 4.1 branch. Oleg > Transparent Content Coding support > ---------------------------------- > > Key: HTTPCLIENT-834 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-834 > Project: HttpComponents HttpClient > Issue Type: New Feature > Components: HttpClient > Affects Versions: 4.0 Beta 2 > Environment: Any > Reporter: James Abley > Fix For: 4.1.0 > > Attachments: 834-2009-03-17.patch, 834-svn-754998.patch, disable-content-coding.patch > > > I would like to see HttpClient features brought up to parity with other libraries, both in Java and other languages. c.f. Python's httplib2 (not yet in the standard library, but many would like to see it in there). That library transparently handles gzip and compress content codings. > This issue is to capture possible solutions to providing this sort of innate functionality in HttpClient, so that users aren't required to know RFC2616 intimately. The HttpClient library should do the right thing and use the network in the most efficient manner possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org