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 Wed, 25 Jan 2006 09:50:44 GMT
On Tue, 2006-01-24 at 21:13 +0100, Oleg Kalnichevski wrote:
> On Tue, 2006-01-24 at 20:53 +0100, Roland Weber wrote:
> > 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.
> > 


I thought about it and now believe it should be possible to change the
design in a way that the process of writing and generating HTTP entities
can be completely driven by HTTP processors and HTTP request/response
interceptors, this allowing to decouple the last remaining bits of
protocol logic from HTTP connection classes. The trouble here is for
this design to be feasible HTTP connections will have to expose raw
input and output streams in the public interface, making it possible for
interceptors to write and read directly from the socket. This is
something I always wanted to avoid, because this puts us back to the
same situation we are now in with HttpClient 3.0 in which we have to
disallow access to HTTP connections in order to avoid their
abuse/misuse. With the present design HTTP connections have full control
over the internal state of the socket. It is the job of HttpConnection
classes to make sure the entity content is correctly delimited and the
underlying raw socket is in a valid state and can be used further.

Maybe this is a price worth paying for a cleaner protocol code? I am not
entirely convinced at the moment. Opinions?


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

View raw message