Thanks Mike. I confess I didn't read the JavaDoc very thoroughly. Despite your concerns around caching of Credentials, in the specific case where this loop occurs the provider is indeed called every time, so maintaining a local count does the trick.
I look forward to migrating to v4.0 in the near future, so for now all is good. Thanks again. Jason. On Wed, Dec 10, 2008 at 2:55 AM, Michael Clark <[EMAIL PROTECTED]> wrote: > Jason Polites wrote: > >> We have "solved" this by making our CredentialsProvider >> implementation maintain an internal record of the number of times it >> has been called, however on face value the code Commons HttpClient >> code does not appear to deal with credentials that fail continuously. >> > > Your solution actually does seem to be somewhat in line with the JavaDoc > for the CredentialsProvider interface: "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." > > However, I see that the CredentialsProvider JavaDoc is also not very clear > about explaining the contract on how the CredentialsProvider will be used; > specifically: when and how often will the CredentialsProvider#getCredentials > method will be invoked? This is not explained, and also there is this > comment to be worried about: > > "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." > > If caching were to happen, it would mean the CredentialsProvider wouldn't > be able to properly track the number of times the credentials it had > provided were actually used. > > A possibly more deterministic solution might be to call > HttpMethod#setDoAuthentication(false) on all the methods you execute. This > will (to the best of my knowledge) "turn off" HttpClient's automatic > handling of authentication challenges. This moves the responsibility for > reacting to authentication challenges (e.g. 401s, 407s, ...) into your > application logic, where you could maintain and increment a counter. > > I agree, however, that some sort of max auth attempts counter internal to > HttpClient 3.x would be the nicest of all. Unfortunately, it doesn't seem > to be there, and with everyone's energy now focused on HC 4.0, I am not sure > if you could expect such a feature to be implemented in the 3.x line. > Someone more familiar with the project could probably answer this better > than I can. > > regards, > > Mike > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
