Torsten, This is a conscious design decision. The reason for these wrappers' existence is to ensure the reliability of persistent connections.
(1) AutoCloseInputStream ensures the entire content body is consumed upon connection release thus making it reusable for other requests. Consider the situation when the response body is consumed only partially by the caller of HttpClient. (2) ContentLenghtInputStream does not permit reading beyond the advertised content length. Consider the fact that it is a common practice to write code to consume the content until the end of the stream (-1). With the persistent connection (kept alive by the server) this approach would fall flat. We are perfectly aware of shortcomings of the existing HttpClient API. It is butt ugly, plain and simple. I guess I am entitled to such a strong opinion as I have been maintaining HttpClient for years on a day to day basis. HttpClient is currently being rewritten and its API redesigned from scratch to address those shortcomings and provide a flexible platform one could use to build client-, proxy- and server-side HTTP services. I hope we will have a much cleaner and powerful API as a result: http://wiki.apache.org/jakarta-httpclient/HttpClientApiRedesign There's already enough code in the SVN to check out already and get a feel of how things are shaping up http://svn.apache.org/repos/asf/jakarta/httpclient/trunk/http-common/ Oleg On Sat, 2005-06-25 at 20:22 +0200, Torsten Curdt wrote: > Can someone explain why the SocketInputStream > is wrapped in an AutoCloseInputStream as well > as a ContentLenghtInputStream. > > This is currently byting me in the ass and > I would at least like to understand why > a read with the return code of -1 is so > bad that everything has to be wrapped like > this. > > Just curious ...I assume there must be a reason > > cheers > -- > Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
