[
https://issues.apache.org/jira/browse/HTTPCLIENT-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14564782#comment-14564782
]
Michael Osipov commented on HTTPCLIENT-1651:
--------------------------------------------
bq. Do we really need two variables: decompressionEnabled and
contentCompressionEnabled?
While one seems reduntant, they are different. The latter requests the server
to compress, the former instructs HttpClient to decompress (some folks maybe
want to have the zipped stream and not decomressed).
If you think we don't need this flexibility, I don't mind to collapse into
contentCompressionEnabled just as in {{HttpClientBuilder}}.
bq. Should not decompressionEnabled rather be contentDecompressionEnabled?
Yes, this is what I said before. Deprecation with a separate ticket.
> Add ability to disable content compression on a request basis
> -------------------------------------------------------------
>
> Key: HTTPCLIENT-1651
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1651
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.4.1
> Reporter: Michael Osipov
> Assignee: Michael Osipov
> Fix For: 4.5, 5.0
>
>
> We use one client for serveral, different requests. Most of the are
> {{application/xml}} where compression is appropriate but some transport big
> binary data. Those requests drop from 30 MB/s to 5 to 7 MB/s.
> Unfortunately, compression can only be disabled client-wide. A
> {{RequestConfig}} or {{HttpContext}} boolean flag for
> {{RequestContentEncoding}} processor would be great.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
