Do not resolve unresolved address for request if the first handler in pipeline is SocksProxyHandler
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 35.1k
- Forks
- 16.3k
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 143
Description
Expected behavior
Some interface for handlers (for example CanConnectUnresolved) that will force Netty to not resolve unresolved addresses for requests with the first handler that implemented this interface.
Socks5ProxyHandler & Socks4ProxyHandler have support for unresolved addresses and can be marked with this interface. It's a very good way for actual proxy usage because this way address will not be resolved in the restricted network (e.g. Russian internet :( ) where DNS answers can be compromised.
Actual behavior
Netty always forces address resolving before starting the request pipeline.
Steps to reproduce
Start an HTTP request to the unresolved socket address.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how request addresses are resolved before the pipeline begins, then inspect Socks5ProxyHandler and Socks4ProxyHandler for their unresolved-address support. Determine how the first handler in the pipeline can influence resolution, and verify that HTTP requests using these proxy handlers retain unresolved addresses while other requests keep their existing behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- networking
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100