[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682639#action_12682639
 ] 

Oleg Kalnichevski commented on HTTPCLIENT-834:
----------------------------------------------

I was thinking about something along this line:

{{{
enum ContentCoding { identity, gzip, deflate };
}}}    

{{{
@SuppressWarnings("unchecked")
Collection<ContentCoding> codings = (Collection<ContentCoding>) 
request.getParams().getParameter(
                "http.protocol.accept-encoding");
if (codings != null) {
     // Add Accept-Encoding header
}
}}}

>> Although thinking about that, the new interceptor is getting added before 
>> the client has a chance to add an interceptor, so the new ones that I've 
>> written 
>> will fire before a user-provided one gets a chance to handle the request 
>> response.Is that the issue? 

I am afraid it is. The content processor in its current form will break 
existing code that relies on protocol interceptors to transparently handle 
content encoding. This is the reason I would like to have an explicit 
configuration parameter the user would have to set in order to enable content 
processing.

>> Can you point me at an example of something similar that already exists, for 
>> configuration parameters? 

Take a look at the default header interceptor, which populates HTTP request 
headers dynamically based on a configuration parameter

http://hc.apache.org/httpcomponents-client/httpclient/xref/org/apache/http/client/protocol/RequestDefaultHeaders.html

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 3
>         Environment: Any
>            Reporter: James Abley
>         Attachments: 834.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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Reply via email to