[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

namloan updated HTTPCLIENT-2350:
--------------------------------
    Summary: Option to prevent hostname resolution to InetAddress  (was: 
Prevent hostname resolution)

> 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|[https://github.com/bisq-network/bisq2]] 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 [this 
> post]([http://stackoverflow.com/a/25203021/5616248)] - 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 [this 
> commit]([https://github.com/bisq-network/bisq2/pull/2990/commits/f93ece314fd16036e0d748ce2c6d9f79ba10e762]).
>  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]([https://github.com/bisq-network/bisq2/blob/main/network/network/src/main/java/bisq/network/http/TorHttpClientConnectionOperator.java#L117-L119]).
> 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.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Reply via email to