You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Ortwin Glück (JIRA)" <ji...@apache.org> on 2007/01/12 09:08:27 UTC
[jira] Commented: (HTTPCLIENT-620) If CredentialsProvider is not
interactive, but programmatic (e.g. fetches credentials from database) and
credentials are wrong the httpclient will attempt to connect until network
connections limit is exhausted on the machine and will not fail.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464115 ]
Ortwin Glück commented on HTTPCLIENT-620:
-----------------------------------------
The API Doc of CredentialsProvider says:
"HttpClient makes no provisions to check whether the same credentials have been tried already. It is a responsibility of the custom credentials provider to keep track of authentication attempts and to ensure that credentials known to be invalid are not retried. HttpClient will simply store the set of credentials returned by the custom credentials provider in the http state object and will attempt to use these credentials for all subsequent requests with the given authentication scope."
Is that not feasible for your case?
> If CredentialsProvider is not interactive, but programmatic (e.g. fetches credentials from database) and credentials are wrong the httpclient will attempt to connect until network connections limit is exhausted on the machine and will not fail.
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-620
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-620
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 3.0.1
> Environment: Windows XP, Java 5.
> Reporter: Andriy Proskuryakov
>
> Happens if CredentialsProvider is not interactive (does not bring dialog every time it is asked for credentials), but programmatic (e.g. fetches credentials from database).
> If credentials returned by provider are wrong the httpclient will not fail after few attempts to connect, but will continue attempts to connect until network connections limit is exhausted on the machine.
> Instrumenting getCredentials method shows it being called hundreds of times in a matter of few seconds, netstat will show hundreds of connections in the TIME_WAIT state.
> I believe the executeMethod of the HttpMethodDirector is responsible (loop on line 141). If processAuthenticationResponse (line 192) fails, the retry is set to true and it attempts to connect again.
> Here is stack trace dumped from getCredentials:
> java.lang.Exception: Stack trace
> at java.lang.Thread.dumpStack(Unknown Source)
> at com.beacon.proxy.impl.CredentialPreferences.getCredentials(CredentialPreferences.java:30)
> at org.apache.commons.httpclient.HttpMethodDirector.promptForProxyCredentials(HttpMethodDirector.java:892)
> at org.apache.commons.httpclient.HttpMethodDirector.processProxyAuthChallenge(HttpMethodDirector.java:772)
> at org.apache.commons.httpclient.HttpMethodDirector.processAuthenticationResponse(HttpMethodDirector.java:665)
> at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:192)
> at org.apache.commons.httpclient.ProxyClient.connect(ProxyClient.java:202)
> at com.beacon.proxy.impl.TunnelingSocketFactory.createSocket(TunnelingSocketFactory.java:101)
> at com.beacon.proxy.impl.SecureSocketFactory.createSocket(SecureSocketFactory.java:89)
> at com.beacon.proxy.impl.SecureSocketFactory.createSocket(SecureSocketFactory.java:65)
> at com.beacon.commons.net.ConnectionTypeSocketFactory.createSocket(ConnectionTypeSocketFactory.java:26)
> at com.beacon.proxy.ConnectionChecker$1.run(ConnectionChecker.java:72)
> We made a hack to circumvent this for our use (just allow few attempts) and then exit. Below is the patch.
> You would certainly want something better for the fix, but the patch can help in understanding the problem:
> Index: src/java/org/apache/commons/httpclient/HttpMethodDirector.java
> ===================================================================
> --- src/java/org/apache/commons/httpclient/HttpMethodDirector.java (revision 11183)
> +++ src/java/org/apache/commons/httpclient/HttpMethodDirector.java (working copy)
> @@ -138,7 +138,11 @@
> try {
> int maxRedirects = this.params.getIntParameter(HttpClientParams.MAX_REDIRECTS, 100);
>
> - for (int redirectCount = 0;;) {
> + int authattempts = 0;
> + // Stop trying to connect if the number of authentication attempts exceeds 6.
> + // Chose 6, an even number twice 3, because NTLM requires two challenges per
> + // authentication attempt.
> + for (int redirectCount = 0; authattempts < 6;) {
>
> // make sure the connection we have is appropriate
> if (this.conn != null && !hostConfiguration.hostEquals(this.conn)) {
> @@ -191,6 +195,7 @@
> if (isAuthenticationNeeded(method)) {
> if (processAuthenticationResponse(method)) {
> LOG.debug("Retry authentication");
> + ++authattempts;
> retry = true;
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org