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

James Abley commented on HTTPCLIENT-834:
----------------------------------------

1) OK, thanks for the clarification. That pretty much ties with my 
understanding, but I thought it was a reasonable approach at the time and 
seemed in line with recommendations from Java Concurrency in Practice. I've 
removed the usage as you suggested.

2) I initially thought you wanted to specify quality values. But you're 
describing something similar. I'm still not clear why that requires 
configuration. If the user doesn't want the interceptor to indicate to the 
server that various content codings are supported, the user can specify their 
own Accept-Encoding header for the request and the request won't be altered and 
the response won't be processed by the new interceptors. Indeed, that behaviour 
is there to ensure that it doesn't break any existing clients that may be using 
an interceptor already to support this functionality. 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? What else am I missing? Can you point me at an example of something 
similar that already exists, for configuration parameters?

As as aside, is there any reason why the Javadocs aren't built as part of the 
site hosted at apache?

> 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