[
https://issues.apache.org/jira/browse/HTTPCLIENT-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754688#action_12754688
]
Oleg Kalnichevski commented on HTTPCLIENT-834:
----------------------------------------------
> Could you elaborate as to why you feel ContentEncodingProcessor should be
> split out?
I _personally_ prefer fine-grained interceptors, one per unit of work or a
header type. For instance, one may want to remove the request interceptor that
generates Accept-Encoding headers while still keeping the Content-Encoding
response interceptor in the protocol chain.
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,
> 834-svn-r811556.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: [email protected]
For additional commands, e-mail: [email protected]
