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

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

> TODOs I've found relate to adding support for compress Content-Encoding

If you think compress is completely useless, we still have to make sure 
HttpClient reacts intelligently when encounters compress coded content, for 
instance by throwing an exception

> The request / response interceptors currently set a flag in the context to 
> show whether the response should be processed. 
> Should that aspect be retained if I split them out?

I _personally_ do not think the flag is necessary anymore, but I do not want to 
impose a particular way of doing things onto you

> Also, should ClientContext be a class rather than an interface? It just 
> contains constants, rather than defining any sort of abstraction.

Roland (who is no longer involved in the project) had a tendency to prefer 
interfaces over classes for defining constants, mainly because of support for 
multiple inheritance. Now it is too late.

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]

Reply via email to