Created an attachment (id=11253)
example diff from a modified 2.0rc2

Credit for the previous diff goes to Sumeet Thadani, another developer on our team.

Somehow I can't help thinking that SOCKS parameters do not really belong to
HostConfiguration. I would rather see them in HttpState or in the HttpParam
collection. I suggest we address this problem in the 3.0 (4.0, that is) timeframe.

Oleg

I agree that this probably won't make it in until the release after next (4.0). In the mean time we could
refactor it into a stand-alone Socket factory and include it in contrib. How does that sound?

Mike

Whatever's easiest for you folks is fine for us. We're going to continue using
a customized version of HttpClient for the indefinite future, so it doesn't
much matter where it goes in the official version.

Storing the SOCKS info in HostConfiguration was more because we consider a
SOCKS proxy to be on the same footing as an HTTP Proxy (in the sense that
they're both proxies), and HTTP proxy was stored in HostConfig.

That's the point. I can't help thinking that proxy settings do not really belong
to HostConfiguration at all, as one would very rarely need to change proxy on a
per host basis. In the overwhelming majority of cases there's only one proxy the
user would want to deal with. So, I'd rather see proxy settings moved to
HttpParams, but that would be too radical for 3.0.

Oleg

Just one comment, please keep in mind those of us that use multi-homed hosts.
There can be times where traffic on one NIC will require use a a proxy where
traffic directed through another will not.

Oleg,

Proxy settings are 'manual routing' on the application layer of the protocol
stack. Therefore proxy settings must remain a per host property in any case.
Even if most proxy users will only use one proxy setting for all their
connections, we must not restrict HttpClient to this most common case. I think
it is an essential flexibility to be able to use a specific proxy per connection.

At our company for instance, we have access to the intranets of some of our
clients. It makes sense to set up one proxy server for each of those
connections. With HttpClient I can then access any host in those intranets
depending on the proxy setting.
Also, if we ever want to implement PAC (auto config) we need to be able to use
one setting per host.

Odi, All I am saying is that HttpParams might be a better place for proxy
settings, as HostConfiguration is getting a little too messy IMO. I am not
trying to say that we should not support multiple proxies and different proxy
types. Let's just consider leveraging HttpParams as it has been specifically
designed to allow parameter settings at client | method | connection level

Oleg

• • • HTTPCLIENT-448 has been marked as a duplicate of this bug. ***

ClientConnectionOperator.openConnection has access to HttpParams and HttpContext.
I think that's enough to address this requirement by plugging in a custom CCO.

HttpRoute does not make provisions for representing socks proxies. They could be inserted into the route as a proxy with socks: protocol, to make the connection manager socks-aware. That would throw off a lot of the upper layers though.
Another way to represent the socks proxy in the route would be as the "local address". That should not cause problems in the upper layers, you just can't combine socks proxies and actual local addresses that way.

cheers,
Roland