-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Connection pooling broken when using proxy over SSL #364
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
Comments
You are seeing the google content twice because you are passing requestBuilder1.build() to executeRequest both times. |
Like @peterox said, there might be an issue with connection pool w/ proxies, but the example you provided is flawed and you send |
I too have seen this problem before in our setup (http://stackoverflow.com/questions/18021722/ssl-and-http-proxy-with-java-client-issues-connectionclosedexception). Another symptom is that the response body of the messages would be scrambled. Our simplest solution was to create a new connection for each SSL termination (disable the ssl conn pool - terribly inefficient I know). As you might expect, we more recently we have been having problems with the proliferation of connections - I'd love to see this fixed! |
Fixing sample code to properly demonstrate problem. |
What if we make the pool key |
@slandelle That would work :-) |
Will go this way for AHC 1, not to break connectionPoolKeyStrategy, and will change connectionPoolKeyStrategy in AHC 2 so that it takes the proxyURI. Thanks! |
The connection pool logic in NettyAsyncHttpProvider does not appear to be working when proxying over SSL.
URI connectionKeyUri = useProxy? proxyServer.getURI() : uri;
channel = lookupInCache(connectionKeyUri, request.getConnectionPoolKeyStrategy());
What appears to be happening is that request #1 creates a new connection keyed to the proxy address and properly issues an HTTP CONNECT for the first host. Request #2 targets a different host via the same proxy, pulls the cached connection since the proxy address is the same but then ends up sending the request to wrong host since that connection is still connected to the first host.
I can hack up NettyAsyncHttpProvider.java if needed by creating a fake URI in the format : scheme://targetHost.proxyHost:proxyPort/ when ssl + proxy is used. The proper solution however would seem to require changing the ConnectionPoolKeyStrategy interface since a URI alone is not enough to correctly compute the pool key.
The following code will re-create the problem.
The text was updated successfully, but these errors were encountered: