[
https://issues.apache.org/jira/browse/HTTPCLIENT-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
namloan updated HTTPCLIENT-2350:
--------------------------------
Description:
In Bisq2 [1] we are querying .onion endpoints through HTTP to retrieve some
data. To do this, it's needed to connect to through a SOCKS proxy and let it
resolve the hostname through the Tor network as a public DNS resolution will
fail. In HTTP client 4.x we had it implemented as explained in [2]- using a
FakeDNSResolver and custom socket factories that do not try to resolve the
.onion hostname to an InetAddress.
We've just migrated to HttpClient 5.4.1. Finding out how to do this required
extensive hours of debugging the library, in particular preventing the public
DNS resolution as custom socket factories are deprecated. Find our solution in
[3]. In essence, we created our own PoolingTorHttpClientConnectionManager to be
able to inject our own HttpClientConnectionOperator that doesn't attempt to
resolve the .onion hostname to an InetAddress [4]
Is there a simpler way to this? If not, it would be great to count on a simpler
option so that we can remove our own connection manager and connection operator
given that they are mostly duplicated code from the library.
[1] [https://github.com/bisq-network/bisq2]
[2]
[http://stackoverflow.com/a/25203021/5616248|http://stackoverflow.com/a/25203021/5616248)]
[3]
[https://github.com/bisq-network/bisq2/pull/2990/commits/f93ece314fd16036e0d748ce2c6d9f79ba10e762]
[4]
[https://github.com/bisq-network/bisq2/blob/main/network/network/src/main/java/bisq/network/http/TorHttpClientConnectionOperator.java#L117-L119]
was:
In Bisq2 [1] we are querying .onion endpoints through HTTP to retrieve some
data. To do this, it's needed to connect to through a SOCKS proxy and let it
resolve the hostname through the Tor network as a public DNS resolution will
fail. In HTTP client 4.x we had it implemented as explained in [2]- using a
FakeDNSResolver and custom socket factories that do not try to resolve the
.onion hostname to an InetAddress.
We've just migrated to HttpClient 5.4.1. Finding out how to do this required
extensive hours of debugging the library, in particular preventing the public
DNS resolution as custom socket factories are deprecated. Find our solution in
[3]. In essence, we created our own PoolingTorHttpClientConnectionManager to be
able to inject our own HttpClientConnectionOperator that doesn't attempt to
resolve the .onion hostname to an InetAddress [4]
Is there a simpler way to this? If not, it would be great to count on a simpler
option so that we can remove our own connection manager and connection operator
given that are mostly duplicated code from the library.
[1] [https://github.com/bisq-network/bisq2]
[2]
[http://stackoverflow.com/a/25203021/5616248|http://stackoverflow.com/a/25203021/5616248)]
[3]
[https://github.com/bisq-network/bisq2/pull/2990/commits/f93ece314fd16036e0d748ce2c6d9f79ba10e762]
[4]
[https://github.com/bisq-network/bisq2/blob/main/network/network/src/main/java/bisq/network/http/TorHttpClientConnectionOperator.java#L117-L119]
> Option to prevent hostname resolution to InetAddress
> ----------------------------------------------------
>
> Key: HTTPCLIENT-2350
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2350
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
> Affects Versions: 5.4.1
> Reporter: namloan
> Priority: Minor
>
> In Bisq2 [1] we are querying .onion endpoints through HTTP to retrieve some
> data. To do this, it's needed to connect to through a SOCKS proxy and let it
> resolve the hostname through the Tor network as a public DNS resolution will
> fail. In HTTP client 4.x we had it implemented as explained in [2]- using a
> FakeDNSResolver and custom socket factories that do not try to resolve the
> .onion hostname to an InetAddress.
>
> We've just migrated to HttpClient 5.4.1. Finding out how to do this required
> extensive hours of debugging the library, in particular preventing the public
> DNS resolution as custom socket factories are deprecated. Find our solution
> in [3]. In essence, we created our own PoolingTorHttpClientConnectionManager
> to be able to inject our own HttpClientConnectionOperator that doesn't
> attempt to resolve the .onion hostname to an InetAddress [4]
> Is there a simpler way to this? If not, it would be great to count on a
> simpler option so that we can remove our own connection manager and
> connection operator given that they are mostly duplicated code from the
> library.
>
> [1] [https://github.com/bisq-network/bisq2]
> [2]
> [http://stackoverflow.com/a/25203021/5616248|http://stackoverflow.com/a/25203021/5616248)]
> [3]
> [https://github.com/bisq-network/bisq2/pull/2990/commits/f93ece314fd16036e0d748ce2c6d9f79ba10e762]
> [4]
> [https://github.com/bisq-network/bisq2/blob/main/network/network/src/main/java/bisq/network/http/TorHttpClientConnectionOperator.java#L117-L119]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
