hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: HttpComponents: entities and connections
Date Tue, 24 Jan 2006 20:13:49 GMT
On Tue, 2006-01-24 at 20:53 +0100, Roland Weber wrote:
> Hi Oleg,
> 
> I am wondering how to detect whether a response entity has been read
> completely, or whether the rest of the response needs to be skipped
> before the connection can be re-used?
> 

Hi Roland,

Calling InputStream#close() on the entity's input stream  will ensure
the content is consumed in its entirety and the connection is safe to be
re-used. 

> While reading the source of the client connection and entity generator
> in this context, I also realized that the entity handling is quite
> different from what I had expected. The biggest problem I see with the
> current design is that the outgoing transport encoding is handled for
> the request entities by RequestContent (for the header) *and* by the
> EntityWriter (for the streams), and that incoming transport encoding
> is handled by the EntityGenerator. I thought that interpretation of
> response headers is the responsibility of the response interceptors
> and the layers above, like method director and application. But some
> of it is done in the connection.
> 

I do recognize this as a design imperfection and am open to consider
alternatives. One possibility could be to do away with EntityWriter and
EntityGenerator entirely and move the functionality of these and related
classes to the respective *HttpConnection classes and interceptors. Let
me think this over a little.

> I assume that this design was driven by the goal to have a connection
> which is useful without the RequestExecutor, and which does not expose
> a mutable interface for the response. But the result is asymmetric and
> has a somewhat fuzzy arrangement of responsibilities. I don't have an
> alternative to offer yet, just wanted to let you know that my thoughts
> are spinning around this point.
> 

Patches (or ideas) are very welcome

Oleg

> cheers,
>   Roland
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Mime
View raw message