hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-834) Transparent Content Coding support
Date Tue, 17 Mar 2009 11:32:56 GMT

    [ 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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message