hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject Re: [HttpCore] Proxy Support
Date Mon, 21 Aug 2006 19:43:05 GMT
Hi Oleg,

>> Being proxied or not is a runtime
>>property, and can not be reflected in the class hierarchy.
> I am not sure I agree with that. From the RFC 2616 standpoint there is
> no difference between proxied and plain client HTTP connection.

I think this may be a rectangle vs. square problem. Mathematically,
every square is a rectangle. Still, it's not a good idea to derive
a square class from a rectangle class :-) (unless it is read-only)
RFC 2616 considers connections as something to send data over. But
our connection objects are more, since they include the logic to
establish the connection. Having connection objects that only know
how to establish a plain connection, and others that know how to
tunnel over a proxy sounds wrong to me.

> The connection itself should
> not be aware of this distinction.

Then we have to factor out the code to establish the connection
and turn the connection into a simple container for the socket,
which is filled from the outside.

> The special case is not connection proxying but rather connection
> tunneling. My first knee-jerk reaction was to put all the tunneling code
> into a separate super class

I think inheritance is the problem, not the solution here.

>>If it is proxied without (real) tunnelling, it can be kept
>>alive even if the next request is going to a different target host
>>but through the same proxy.
> Presently this is one of deficiencies of HttpClient 3.x (MTHCM to be
> exact). We definitely should try to make HttpClient 4.0 a bit smarter
> about pooling proxied connections. 

OK. Will be tough though. I've taken a look at MTHCM recently.
It's massive.

>>I believe that the connection itself would be a good place to
>>implement the logic for deciding whether it is pointing correctly.
> I rather lean toward keeping this kind of logic in a connection manager,
> but am open to consider alternative approaches. In my opinion the job of
> connection is to shove around HTTP messages, whereas the decision about
> re-usability of connections should be left up to a connection manager

My problem is that I don't want to make HttpAsync dependent on a
connection manager. If you have a look at the open issues I have
created for HttpAsync, you'll notice that it needs a completely
different connection management interface. I've already pushed that
to a future release, to reduce the bulk of work to a more manageable
size. In fact, I had a very bad day a few weeks ago when thinking
about HttpAsync, and pushing connection management to a future
release was the one thing that helped me get over that mood.

Regarding the responsibilities of connections and connection managers,
my idea was to let the connection decide whether it is pointing to the
target, and if it does the connection manager (or dispatcher) can ask
the connection reuse strategy whether to keep it alive or not. Or
something along that line.

>>A minor detail is that only the HttpProxyConnection has an
>>isSecure() method. A non-proxied connection can be secure, too :-)
>>Another minor detail is the ProxyHost class, which is not used
>>anywhere in the API, but only by the DefaultHttpProxyConnection.
>>I'm not sure whether it adds any value.
> Let's fix it.

OK. I'll try to come up with a patch this week.

> My suggestion would be to port MTHCM to the new API, hack up a very
> simple HttpClient prototype (no cookies, no authentication, no
> redirects) and see if we end up with some generic aspects that may prove
> useful in HttpAsync or HttpCore. It may be a little easier to observe
> commonalities rather than trying to 'guest' them.

Do we need MTHCM for the proxy part?


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

View raw message