Re: importing certs with private key into keystore

- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesus M. Salvo Jr. Mobile Internet Group Pty Ltd (formerly Softgame International Pty Ltd) M: +61 409 126699 T: +61 2 94604777 F: +61 2 94603677 PGP Public key: http://pgp.mit.edu

Re: client certs - how to choose which cert to use?

Tim Wild wrote: Hi all, Using a link to Sun code that a few people have posted before, I have client authentication working using HttpClient by creating my own SecureProtocolSocketFactory. The problem i'm having is that it seems to automatically choose a certificate without asking me which

Re: client certs - how to choose which cert to use?

an https server. I also tried specifying the SSLProtocolSocketFactory. Do I still need to use a SecureProtocolSocketFactory, or should the default one work? If the default one should work, could you think what I might have missed? Thanks Tim Jesus M. Salvo Jr. wrote: Tim Wild wrote: Hi all, Using

Re: Persistent HTTPS connections

/DefaultMethodRetryHandler.html#62 Oleg -Original Message- From: Jesus M. Salvo Jr. [mailto:[EMAIL PROTECTED] Sent: Thursday, May 13, 2004 7:40 To: [EMAIL PROTECTED] Subject: Persistent HTTPS connections Using HttpClient 2.0 JDK 1.4.2_04 on Fedora Is there anything special that I have to do to make use

Re: Persistent HTTPS connections

One small thing though. Why is setMethodRetryHandler() defined in HttpMethodBase class instead of the HttpMethod interface ? Jesus M. Salvo Jr. wrote: Hi Oleg, Thanks for that. I have now implemented my own MethodRetryHandler and got rid of my custom loop / retry. Cleaner log files for my

Re: Persistent HTTPS connections

Some clarifications below. Jesus M. Salvo Jr. wrote: What I am seeing with ethereal is that, after 30 seconds of no activity ( no TCP ACKs whatever on the socket ), the web server sends a a TLS alert. So what actually happens is this: 1) Send one HTTP POST to a URL, which works and I get

Re: Persistent HTTPS connections

Jesus M. Salvo Jr. wrote: Question is, was I correct in initially assuming that MultiThreadedHttpConnectionManager should have handled this case ? e.g... .detected that the exception, and retried the HTTP POST by creating a new HTTPS socket ? What I have done now is, if I get

Persistent HTTPS connections

Using HttpClient 2.0 JDK 1.4.2_04 on Fedora Is there anything special that I have to do to make use of persistent HTTP(S) connections with HttpClient other than using MultiThreadedHttpConnectionManager ? Basically, what I am doing is the following ( more explanation after the snippet of the

Re: Question on Timeouts

[EMAIL PROTECTED] wrote: Hello, I'm using your product for an application that we're building (that fetches some HTTP content) and I'm running into an issue where it isn't timing out ..snip... --This is how we're connecting - HttpClient client = new

CLOSE_WAIT, logging

HttpClient RC 2.0 64-bit Solaris 8 JDK 1.3.1_09 I am seeing lots of sockets in CLOSE_WAIT, despite the fact that postMethod.releaseConnection(); is called. This has happened so far against 2 of our ( different ) clients' webservers, mostly to Tomcat / Coyote. The problem with CLOSE_WAIT sockets

Re: CLOSE_WAIT, logging

close() on the underlying HttpConnection. Thanks, Sam On Sunday, December 7, 2003, at 10:31 PM, Jesus M. Salvo Jr. wrote: From a snoop capture, Apache Coyote sent a TCP FIN 20 seconds after the last ACK from the client. But the client did not sent a TCP FIN of its own, leaving the socket

Re: CLOSE_WAIT, logging

Sam Berlin wrote: That's relying a bit too much on garbage-collection, which can happen at any time. You should never rely on garbage collection to clean up native resources, like open sockets, especially if you're concerned about such low level things as a CLOSE_WAIT state. Thanks, Sam

Re: CLOSE_WAIT, logging

Michael Becke wrote: Agreed. Relying on garbage collection is not really an option. There are only 2 real choices that I can see: 1) add a method on HttpMethod to explicitly close a connection. This would be the simplest solution, but I think it would also defeat the purpose of

Re: RFE: Method to return an InputStream that includes both HTTPheaders and HTTP body

Definitely ... unless of course setFollowRedirect() is set to false. Ortwin Gl|ck wrote: Jesus M. Salvo Jr. wrote: At the moment, the HttpMethod interface has a method getResponseBodyAsStream() that returns an InputStream of the HTTP body. I need a method that returns the _entire_ HTTP

Re: RFE: Method to return an InputStream that includes both HTTPheaders and HTTP body

I should qualify that the line containing the HTTP response code _not_ be included in the returned InputStream Ortwin Gl|ck wrote: Jesus M. Salvo Jr. wrote: At the moment, the HttpMethod interface has a method getResponseBodyAsStream() that returns an InputStream of the HTTP body. I need

Re: Redirect to a different domain not supported?

Did Oleg's work on the redirect made it to alpha3 rc4? Oleg Kalnichevski wrote: Folks I was going to start working on it today. If there are any other takers, please let me know Cheers Oleg On Mon, 2003-02-24 at 07:27, Jeffrey Dever wrote: This is currently on the todo list. Refer to the

Redirect to a different domain not supported?

Using Alpha2, when I do an HTTP GET from an Australian ISP to www.google.com with setFollowRedirects set to true, HttpClient client = new HttpClient(); HostConfiguration config = new HostConfiguration(); config.setHost( www.google.com, 80, http ); client.setHostConfiguration( config

Re: Redirect to a different domain not supported?

] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesus M. Salvo Jr. Mobile Internet Group Pty Ltd (formerly Softgame International Pty Ltd) M: +61 409 126699 T: +61 2 94604777 F: +61 2 94603677 PGP Public key