Return-Path: Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list commons-httpclient-dev@jakarta.apache.org Received: (qmail 5549 invoked from network); 3 Apr 2003 15:36:06 -0000 Received: from unknown (HELO KCCXOEX10.corp.kpmgconsulting.com) (57.80.136.22) by daedalus.apache.org with SMTP; 3 Apr 2003 15:36:06 -0000 Received: from kccxoex03.corp.kpmgconsulting.com ([57.80.136.6]) by KCCXOEX10.corp.kpmgconsulting.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Apr 2003 15:37:31 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: SSL Performance Problem Date: Thu, 3 Apr 2003 16:36:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SSL Performance Problem Thread-Index: AcL59ZtCsCl69K0rTES5PuidNjymkQAAOl4g From: "Kalnichevski, Oleg" To: "Commons HttpClient Project" X-OriginalArrivalTime: 03 Apr 2003 15:37:31.0531 (UTC) FILETIME=[F0B2B5B0:01C2F9F6] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Stupid me ;-) Actually HttpClient uses 3000ms timeout when expecting 100 = (CONTINUE) status code. That has nothing to do with SSL and all my = conspiracy theories. As now 'expect: 100-continue' is disabled per default, HttpClient treats = all 100 status codes it receives as unexpected. This is perfectly ok. = Some HTTP servers do send 100 (CONTINUE) status code even if they are = not asked to do so. Are you using Jetty by any chance?=20 Oleg -----Original Message----- From: Andr=E9 Augusto de Oliveira Arag=E3o [mailto:andre.augusto@ca.tco.net.br] Sent: Donnerstag, 3. April 2003 17:24 To: 'Commons HttpClient Project' Subject: RE: SSL Performance Problem HI! I got the latest nightly build. The times are no more constant, and the performance is now ok. There is a new message in the log: org.apache.commons.httpclient.HttpMethod - Discarding unexpected = response: HTTP/1.1 100 Continue Why is it discarding? Is the server sending me this anyway, or the httpclient is sending the header Expect 100: continue with my post data? Best regards, Andre -----Original Message----- From: Kalnichevski, Oleg [mailto:oleg.kalnichevski@bearingpoint.com] Sent: quinta-feira, 3 de abril de 2003 12:14 To: Commons HttpClient Project Subject: RE: SSL Performance Problem Andre Recently there has been an SSL vulnerability discovered related (very roughly put) to the time it takes the server respond to an invalid authentication request. For more details refer to http://lasecwww.epfl.ch/memo_ssl.shtml I would not be too surprised if newer SSL implementation developed some pre-emptive measures against similar exploits by trying to equalize = response time. It's just a wild guess on my part. By no means being a security = expert I may be wrong about it. Oleg -----Original Message----- From: Andr=E9 Augusto de Oliveira Arag=E3o [mailto:andre.augusto@ca.tco.net.br] Sent: Donnerstag, 3. April 2003 16:55 To: 'Commons HttpClient Project' Cc: 'becke@u.washington.edu' Subject: RE: SSL Performance Problem Thanks Michael, I=B4m trying to send it again, this time as zip file.=20 About the poor performance, I'm measuring time only after receiving the = 100 server response, in the second step of the handshaking process. In the = C++ version I have, I don=B4t know if it does or not the 100 handshaking - I = don't have the code. Anyway, it=B4s much faster, and I don=B4t believe it=B4s = because it=B4s implemented in java. The http version has similar times in the = java and C++ version. Can you point me a similar jsse implementation? What about the constant times? It=B4s the weird thing. It takes the same = time in the first part of the negotiation, when it send the 100 header, and = in the second part - actually when the request is processed in the server. = Any explanations? Regards, Andre -----Original Message----- From: Michael Becke [mailto:becke@u.washington.edu] Sent: quinta-feira, 3 de abril de 2003 11:39 To: Commons HttpClient Project Subject: Re: SSL Performance Problem Hello Andr=E9, Unfortunately it seems that the attachments were stipped from your=20 message. Jeff, Oleg do you have any idea how we can get this fixed? I'm guessing the poor performance with SSL is due to the "Expect:=20 100-continue" header. Try calling setUseExpectHeader(false) on the post = method. I would also suggest using the latest code from CVS or a=20 nightly build. Mike Andr=E9 Augusto de Oliveira Arag=E3o wrote: > HI! >=20 > I think httpclient is having a strange behavior. I=B4m developing a = software > that, among other things, must make performance measurements on web = sites. >=20 > I have a site called https://callcenter.tco.net.br. This site uses, as = you > can see SSL. And I also have this site in a non ssl version - > http://www.tco.net.br/col.=20 >=20 > When I try to measure performance in the = https://callcenter.tco.net.br, I > get always 3000 ms. I can run a dozen times, and I get it over and = over > (with the log turned off), with very small changes - about 4 ms. = It=B4s very > strange. This time is measured only in the second post interaction, = ie, in > the reply to the 100-continue server response. >=20 > When I use the non-ssl version, the time changes at each try, as = expected. >=20 > Other problem is the performance. When I use the non-ssl version, the = time > changes from 800 ms to 1200 ms. Using the https, it=B4s always 3000 = ms. I have > a similar function wrote in C++, and I get similar times using http or > https. Well, https sometimes get to 1500 ms, but generally speaking, = the > degradation is not sensible. >=20 > I=B4m sending my code, and the log generated for both situations, = using the > https and the http site. >=20 > Another question: Why the httpclient always add the Expect: = 100-continue > header? Is it part of the http spec? As I know, it should not be used = on > "normal" situations, ie, when you have a small post to do to the = server. > Correct me If I=B4m wrong. >=20 > I=B4m using 2.0-alpha3-dev. >=20 > Thanks in advance, >=20 > Andre Augusto > TCO Celular >=20 >=20 >=20 >=20 > = ------------------------------------------------------------------------ >=20 > --------------------------------------------------------------------- > To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: = commons-httpclient-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: = commons-httpclient-dev-help@jakarta.apache.org