Github user dmap commented on the issue:
https://github.com/apache/httpcomponents-core/pull/94
> @dmap My first impression is very positive. Changes look concise and
non-intrusive. I have one conceptual question though. Was there any particular
reason for putting `SOCKS` protocol logic into `InternalChannel` instead of a
custom `IOEventHandler` (similarly to `ClientHttpProtocolNegotiator`)?
No, no particular reason. I am not that familiar with the codebase (which
is pretty large) and this was the simplest way I found to implement the
feature. I am happy for it to be done another way.
What I will say is that the SOCKS protocol negotiation is VERY low level.
It has to happen on the wire before anything else... before TLS negotiation,
before HTTP connects etc. I found it difficult to navigate my way through the
source code well enough to achieve this any other way besides using the
{{InternalChannel}} approach.
It is theoretically possible to want to establish an SSL connection to
SOCKS proxy, then do the SOCKS negotiation, but in practice virtually no SOCKS
proxy servers support this. That could be a feature for another day... It
could mean negotiating SSL with the SOCKS proxy and then again (over the same
connection) to the target server (tunnelled through the SOCKS proxy). What fun
that would be. In practice it is unnecessary because if you are negotiating
SSL with the target server all the traffic is secured end-to-end anyway, the
SOCKS proxy just tunnels it through unchanged.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
