Thanks. BTW I traced the execution and saw that the SSL handshake was not the problem. I then realized I could set a timeout for the getmethod: methodget.getParams().setSoTimeout(15000);
That fixed the problem since the methodget was hanging for the non-responsive host. Upgrading to 4.1 seems like a good idea but for now it works!! Ray -----Original Message----- From: Oleg Kalnichevski [mailto:[email protected]] Sent: Tuesday, May 25, 2010 9:22 AM To: HttpClient User Discussion Subject: Re: HttpClient 4.0.1 and Timeout On Mon, 2010-05-24 at 19:17 -0700, Ray Hooker wrote: > Thanks for the reply. I think you are probably right about the SSL handshake > being where it fails. > > With version 4.1, is it possible to deal with the self-signed certificate? Of course. > The code I have for the custom protocol to automatically accept the > self-signed certificate is based on 3.1. > You can always implement a custom socket factory pretty much the same way as with HttpClient 3.1 and exercise fully control over the process of socket initialization. As of release 4.1-alpha2 you have an option of overriding the default JSSE validation process by providing the standard SSLSocketFactory with a custom TrustStrategy implementation. If you choose to go the custom socket factory route, do not forget to set a socket timeout on the SSL socket immediately after connecting it to the remote address. Oleg > Ray > > olegk wrote: > > > > On Mon, 2010-05-24 at 12:21 -0700, Ray Hooker wrote: > >> I am having trouble getting my client to timeout with a non-responsive > >> host. > >> I should say up front that I am doing authentication discovery to setup > >> valid auth credentials for hosts that I am managing. > >> > >> The other big deal is that I am using https and the hosts have > >> self-signed > >> certificates. The reason I mention this it that I had to use a sample > >> for > >> custom protocol handler. This has been deprecated but works nicely: > >> > >> Protocol myhttps = new Protocol("https", (SecureProtocolSocketFactory) > >> new > >> EasySSLProtocolSocketFactory(), 443); > >> > >> Here is my code: > >> ***********************Begin Code Snippet********* (I am importing > >> apache.commons.httpclient version 3.1) HttpClient CTMclient = new > >> HttpClient(); Protocol myhttps = new Protocol("https", > >> (SecureProtocolSocketFactory) new EasySSLProtocolSocketFactory(), 443); > >> Protocol.registerProtocol("https", myhttps); > >> CTMclient.getParams().setAuthenticationPreemptive(true); > >> CTMclient.getState().setCredentials(new AuthScope(AuthScope.ANY_HOST, > >> 443, > >> AuthScope.ANY_REALM), defaultcreds); > >> CTMclient.setConnectionTimeout(15000); > >> **** Note I am setting the timeout. > >> GetMethod methodget = new > >> GetMethod("https://"+CTMurl+"/cgi-bin?tbAction=TB_CONFIG_CALL_STATISTICS";); > >> > >> try { > >> statusCode = CTMclient.executeMethod(methodget); > >> ..................... > >> **********************End Code Snippet ************** > >> > >> This works beautifully so long as the host is responsive. I am able to > >> handle the unsigned certificate transparently and successfully > >> authenticate. > >> The only problem is that with non-responsive hosts, it never times out. > >> I > >> saw some code snippets setting the timeout using httpparms, but I then > >> have > >> to switch to BasicHttpClient and away from httpcommons libraries. I was > >> not > >> able to get the authentication to work. > >> > >> Does anyone have a way to set the timeout other than the above?.. or a > >> pointer to working code examples that include authentication and the use > >> of > >> custom protocol for the self-signed cert? > >> > >> Ray > > > > Ray, > > > > I am confused. The subject mentions HttpClient 4.0.1 but the code posted > > uses 3.x API. > > > > Most likely the request never times out because the connection is > > blocked at the SSL handshake. Please consider upgrading to version 4.x > > which is better equipped to deal with such situations. > > > > Oleg > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
