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 the

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 a

Re: @since tags (3.0alpha1 blocker)

Mike, You rock! I think the 3.0 alpha1 release is ready Oleg On Thu, 2004-05-13 at 06:04, Michael Becke wrote: Docs updated. Mike On May 12, 2004, at 5:53 PM, Oleg Kalnichevski wrote: We are almost there. Before we can cut the release, though, there's one tedious and laborious task

redirect issue with httpclient

hi all, I am using Jakarta HTTPClient to do a post on a website. it seems that after the authentication the page is getting redirected to other location. the significant thing is that its changing the port also. below i am posting the output i am getting from my code. May 13, 2004 12:43:25 PM

RE: Persistent HTTPS connections

John, Please correct me if I am wrong (which may well be the case) SO_TIMEOUT only affects socket read operations. I thought it had nothing to do with SSL inactivity timeout. But it looks like it might. There's another way to deal with recoverable exceptions. You can provide a custom

RE: redirect issue with httpclient

Himanshu, HttpClient 2.0, unfortunately, cannot automatically handle cross-host redirects. But this limitation is not difficult to work around. See the document below http://jakarta.apache.org/commons/httpclient/redirects.html HttpClient 3.0 will address this limitation Oleg -Original

RE: 'Socket closed' exception using

Thank you, guys. I will work in this direction, i.e. investigating what the Connotate's software does with the response, and let you know the results. Sofya -Original Message- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 9:44 PM To: Commons HttpClient

[VOTE] 3.0 alpha 1 release

I propose that we mark the latest code in CVS HEAD as 3.0 alpha 1 and proceed with a release. Please vote as follows: -- Vote: HttpClient 3.0 alpha 1 release [ ] +1 I am in favor of the release, and will help support

Re: [VOTE] 3.0 alpha 1 release

+1 On May 13, 2004, at 7:32 PM, Michael Becke wrote: I propose that we mark the latest code in CVS HEAD as 3.0 alpha 1 and proceed with a release. Please vote as follows: --- --- Vote: HttpClient 3.0 alpha 1 release [ ] +1

Where are the response bits being read over the wire?

Hi All, We are extending classes in an initail effort to instrument DNS, connect, response(first buffer read), and download. The DNS and connect looks pretty good. Where are the bits actually being retrieved over the wire? Overriding HttpMethodBase. byte[] getResponseBody() and adding

Re: Where are the response bits being read over the wire?

Hi Steve, Could it be that most of the responses are less that 4KB? This would explain the zero times since the timer does not start until after the first read. If would suggest setting responseEnd before the while loop. Also, it could be that System.currentTimeMillis() does not provide