Skip to content

Added support for java.net.ProxySelector #362

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 21, 2013

Conversation

jroper
Copy link
Contributor

@jroper jroper commented Aug 19, 2013

Fixes #360.

Summary:

  • Instead of AsyncHttpClientConfig having a ProxyServer, it now has a ProxyServerSelector.
  • Methods that configure a ProxyServer now take the passed in ProxyServer and configure a selector that always returns that ProxyServer.
  • Although I could have moved the nonProxyHosts handling into the ProxyServerSelector implementation, I didn't because users might still configure a ProxyServer per request that has nonProxyHosts configuration, and so this handling needs to go through the current avoidHosts methods.
  • Added an option called useProxySelector that tells async-http-client to use an implementation of ProxyServerSelector that wraps the JDK default ProxySelector. This allows for much more complex proxy selection, such as a proxy.pac based implementation from the Proxy Vole project.
  • Kept the useProxyProperties option and its current implementation, because it offers some things that ProxySelector can't provide, for example, using HTTPS and other protocols to connect to the proxy.
  • Fixed a bug in useProxyProperties nonProxyHosts handling, where only wildcards at the front of the nonProxyHosts config were being honoured, but the JDK docs indicate that wildcards are permitted both at the front and at the end.
  • Fixed a turkish i bug in nonProxyHosts matching.
  • Fixed a bug in the ProxyUtils.createProxy method where it was ignoring the passed in Properties, and going directly to System.getProperty.
  • Documented both useProxyProperties and useProxySelector.

Fixes AsyncHttpClient#360.

* Adds a useProxySelector option that tells async-http-client to use the
  JDK default ProxySelector.
* Adds a ProxyServerSelector interface that AsyncHttpClientConfig and
  ProxyUtils now use.
@jroper
Copy link
Contributor Author

jroper commented Aug 19, 2013

I've also back ported this to 1.7.x for my own purposes, if you're interested in having this in that branch, let me know and I'll create a PR for that too.

jfarcand added a commit that referenced this pull request Aug 21, 2013
Added support for java.net.ProxySelector
@jfarcand jfarcand merged commit 1316688 into AsyncHttpClient:master Aug 21, 2013
@jfarcand
Copy link
Contributor

Thanks!

jfarcand added a commit that referenced this pull request Aug 26, 2013
@ghost ghost assigned jfarcand Aug 27, 2013
@slandelle
Copy link
Contributor

@jfarcand @jroper We have a problem here: InetSocketAddress.getHostString exists only since JDK7! IIRC, @rlubke made the Grizzly provider require JDK7, but the rest of AHC is supposed to be JDK6 compatible.

@jroper
Copy link
Contributor Author

jroper commented Sep 3, 2013

Ok, InetSocketAddress.getHostString can be replace with getHost I believe, the difference being that getHost may do a DNS lookup.

@jroper jroper deleted the proxy-selector branch July 29, 2014 02:08
cs-workco pushed a commit to cs-workco/async-http-client that referenced this pull request Apr 13, 2023
Motivation:

At the moment, AHC assumes that creating a `NIOSSLContext` is both cheap
and doesn't block.

Neither of these two assumptions are true.

To create a `NIOSSLContext`, BoringSSL will have to read a lot of
certificates in the trust store (on disk) which require a lot of ASN1
parsing and much much more.

On my Ubuntu test machine, creating one `NIOSSLContext` is about 27,000
allocations!!! To make it worse, AHC allocates a fresh `NIOSSLContext`
for _every single connection_, whether HTTP or HTTPS. Yes, correct.

Modification:

- Cache NIOSSLContexts per TLSConfiguration in a LRU cache
- Don't get an NIOSSLContext for HTTP (plain text) connections

Result:

New connections should be _much_ faster in general assuming that you're
not using a different TLSConfiguration for every connection.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use ProxySelector API to select proxy when useProxyProperties is true
3 participants