[
https://issues.apache.org/jira/browse/HTTPCLIENT-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved HTTPCLIENT-1273.
-------------------------------------------
Resolution: Fixed
Sebastiano,
Re-throwing of HTTP protocol exception as an i/o exception is intentional. All
HttpClient implementations follow that convention. The problem is that they are
also expected to take care of resource deallocation in case of _any_ abnormal
situation, be it an i/o, HTTP or runtime error. DecompressingHttpClient
obviously was not doing that. Fixed in both SVN trunk and 4.2.x. Please re-test
/ review.
Oleg
> DecompressingHttpClient rethrows an HttpException as an IOException
> -------------------------------------------------------------------
>
> Key: HTTPCLIENT-1273
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1273
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.2.2
> Reporter: Sebastiano Vigna
>
> The execute() method of DecompressingHttpClient catches an HttpException and
> rethrows it as a ClientProtocolException, which is an IOException. The
> documentation and examples state clearly that when an HttpException is
> thrown, resources must be released (abort(), consume(), etc.), but when an
> IOException is thrown, the connection is closed for you. By rethrowing the
> wrong type, people (like me) are deeply puzzled, as after getting an
> IOException an attempt to reuse the connection generates a "still allocated"
> exception, which should not happen (if you believe the documentation).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
