Re: SSL Performance Problem

[Simon Roberts]

This may be getting fixed soon. See the bugtrack item for Jetty:

http://sourceforge.net/tracker/index.php?func=detail&aid=699011&group_id=732
2&atid=107322

The item remains open, and greg is normally pretty good about closing things
when they're done.

Cheers, Simon

- Original Message -
From: "Oleg Kalnichevski" <[EMAIL PROTECTED]>
To: "Commons HttpClient Project" <[EMAIL PROTECTED]>
Sent: Friday, April 04, 2003 6:22 AM
Subject: RE: SSL Performance Problem


> Andre,
> I know for sure Jetty server always sends 100 status code when
> processing POST HTTP/1.1 regardless of 'expect: 100-continue' header
> being present or not. So, it was my guess you were using Jetty
>
> Oleg
>
> On Thu, 2003-04-03 at 20:09, André Augusto de Oliveira Aragão wrote:
> > Oleg,
> >
> > I'm not using Jetty, at least not in this project. The server I'm
monitoring
> > is M$ IIS. Why are you asking?
> >
> > Andre
>
>
>
> -
> 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]

RE: SSL Performance Problem

[Oleg Kalnichevski]

Andre,
I know for sure Jetty server always sends 100 status code when
processing POST HTTP/1.1 regardless of 'expect: 100-continue' header
being present or not. So, it was my guess you were using Jetty

Oleg

On Thu, 2003-04-03 at 20:09, André Augusto de Oliveira Aragão wrote:
> Oleg,
> 
> I'm not using Jetty, at least not in this project. The server I'm monitoring
> is M$ IIS. Why are you asking?
> 
> Andre



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SSL Performance Problem

[André Augusto de Oliveira Aragão]

Oleg,

I'm not using Jetty, at least not in this project. The server I'm monitoring
is M$ IIS. Why are you asking?

Andre


-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: quinta-feira, 3 de abril de 2003 12:36
To: Commons HttpClient Project
Subject: RE: SSL Performance Problem


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? 

Oleg

-Original Message-
From: André Augusto de Oliveira Aragão
[mailto:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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é Augusto de Oliveira Aragão
[mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 16:55
To: 'Commons HttpClient Project'
Cc: '[EMAIL PROTECTED]'
Subject: RE: SSL Performance Problem


Thanks Michael,

I´m trying to send it again, this time as zip file. 

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´t know if it does or not the 100 handshaking - I don't
have the code. Anyway, it´s much faster, and I don´t believe it´s because
it´s 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´s 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:[EMAIL PROTECTED]
Sent: quinta-feira, 3 de abril de 2003 11:39
To: Commons HttpClient Project
Subject: Re: SSL Performance Problem


Hello André,

Unfortunately it seems that the attachments were stipped from your 
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: 
100-continue" header.  Try calling setUseExpectHeader(false) on the post 
method.  I would also suggest using the latest code from CVS or a 
nightly build.

Mike

André Augusto de Oliveira Aragão wrote:
> HI!
> 
> I think httpclient is having a strange behavior. I´m developing a software
> that, among other things, must make performance measurements on web sites.
> 
> 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. 
> 
> 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´s very
> strange. This time is measured only in the second post interaction, ie, in
> the reply to the 100-continue server response.
> 
> When I use the non-ssl version, the time changes at each try, as expected.
> 
> 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´s 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.
> 
> I´m sending my code, and the log generated for both situations, using the
> https and the http site.
> 
> Another question: Why the httpclient always add the Expect: 100-continue
> header? Is it part of the http spec? As I know, it sh

Re: SSL Performance Problem

[Michael Becke]

Yes, it was definitely the 100-continue that was causing the problem. 
3000ms seemed like and awfully round number:)

André, you should not need to handle the 100 status response in your 
code anymore.  This value should no longer be returned by the method.

Mike

Kalnichevski, Oleg wrote:
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? 

Oleg

-Original Message-
From: André Augusto de Oliveira Aragão
[mailto:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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é Augusto de Oliveira Aragão
[mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 16:55
To: 'Commons HttpClient Project'
Cc: '[EMAIL PROTECTED]'
Subject: RE: SSL Performance Problem
Thanks Michael,

I´m trying to send it again, this time as zip file. 

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´t know if it does or not the 100 handshaking - I don't
have the code. Anyway, it´s much faster, and I don´t believe it´s because
it´s 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´s 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:[EMAIL PROTECTED]
Sent: quinta-feira, 3 de abril de 2003 11:39
To: Commons HttpClient Project
Subject: Re: SSL Performance Problem
Hello André,

Unfortunately it seems that the attachments were stipped from your 
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: 
100-continue" header.  Try calling setUseExpectHeader(false) on the post 
method.  I would also suggest using the latest code from CVS or a 
nightly build.

Mike

André Augusto de Oliveira Aragão wrote:

HI!

I think httpclient is having a strange behavior. I´m developing a software
that, among other things, must make performance measurements on web sites.
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. 

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´s very
strange. This time is measured only in the second post interaction, ie, in
the reply to the 100-continue server response.
When I use the non-ssl version, the time changes at each try, as expected.

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´s 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.
I´m sending my code, and the log generated for both situations, using the
https and the http site.
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.
Correc

RE: SSL Performance Problem

[Kalnichevski, Oleg]

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? 

Oleg

-Original Message-
From: André Augusto de Oliveira Aragão
[mailto:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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é Augusto de Oliveira Aragão
[mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 16:55
To: 'Commons HttpClient Project'
Cc: '[EMAIL PROTECTED]'
Subject: RE: SSL Performance Problem


Thanks Michael,

I´m trying to send it again, this time as zip file. 

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´t know if it does or not the 100 handshaking - I don't
have the code. Anyway, it´s much faster, and I don´t believe it´s because
it´s 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´s 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:[EMAIL PROTECTED]
Sent: quinta-feira, 3 de abril de 2003 11:39
To: Commons HttpClient Project
Subject: Re: SSL Performance Problem


Hello André,

Unfortunately it seems that the attachments were stipped from your 
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: 
100-continue" header.  Try calling setUseExpectHeader(false) on the post 
method.  I would also suggest using the latest code from CVS or a 
nightly build.

Mike

André Augusto de Oliveira Aragão wrote:
> HI!
> 
> I think httpclient is having a strange behavior. I´m developing a software
> that, among other things, must make performance measurements on web sites.
> 
> 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. 
> 
> 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´s very
> strange. This time is measured only in the second post interaction, ie, in
> the reply to the 100-continue server response.
> 
> When I use the non-ssl version, the time changes at each try, as expected.
> 
> 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´s 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.
> 
> I´m sending my code, and the log generated for both situations, using the
> https and the http site.
> 
> 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´m wrong.
> 
> I´m using 2.0-alpha3-dev.
> 
> Thanks in advance,
> 
> Andre Augusto
> TCO Celular
> 
> 
> 
> 
> 
> 
> 

RE: SSL Performance Problem

[André Augusto de Oliveira Aragão]

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:[EMAIL PROTECTED]
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é Augusto de Oliveira Aragão
[mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 16:55
To: 'Commons HttpClient Project'
Cc: '[EMAIL PROTECTED]'
Subject: RE: SSL Performance Problem


Thanks Michael,

I´m trying to send it again, this time as zip file. 

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´t know if it does or not the 100 handshaking - I don't
have the code. Anyway, it´s much faster, and I don´t believe it´s because
it´s 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´s 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:[EMAIL PROTECTED]
Sent: quinta-feira, 3 de abril de 2003 11:39
To: Commons HttpClient Project
Subject: Re: SSL Performance Problem


Hello André,

Unfortunately it seems that the attachments were stipped from your 
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: 
100-continue" header.  Try calling setUseExpectHeader(false) on the post 
method.  I would also suggest using the latest code from CVS or a 
nightly build.

Mike

André Augusto de Oliveira Aragão wrote:
> HI!
> 
> I think httpclient is having a strange behavior. I´m developing a software
> that, among other things, must make performance measurements on web sites.
> 
> 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. 
> 
> 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´s very
> strange. This time is measured only in the second post interaction, ie, in
> the reply to the 100-continue server response.
> 
> When I use the non-ssl version, the time changes at each try, as expected.
> 
> 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´s 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.
> 
> I´m sending my code, and the log generated for both situations, using the
> https and the http site.
> 
> 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´m wrong.
> 
> I´m using 2.0-alpha3-dev.
> 
> Thanks in advance,
> 
> Andre Augusto
> TCO Celular
> 
> 
> 
> 
> 
> 
> -
> 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]



-
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 PROTE

RE: SSL Performance Problem

[Kalnichevski, Oleg]

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é Augusto de Oliveira Aragão
[mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 16:55
To: 'Commons HttpClient Project'
Cc: '[EMAIL PROTECTED]'
Subject: RE: SSL Performance Problem


Thanks Michael,

I´m trying to send it again, this time as zip file. 

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´t know if it does or not the 100 handshaking - I don't
have the code. Anyway, it´s much faster, and I don´t believe it´s because
it´s 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´s 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:[EMAIL PROTECTED]
Sent: quinta-feira, 3 de abril de 2003 11:39
To: Commons HttpClient Project
Subject: Re: SSL Performance Problem


Hello André,

Unfortunately it seems that the attachments were stipped from your 
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: 
100-continue" header.  Try calling setUseExpectHeader(false) on the post 
method.  I would also suggest using the latest code from CVS or a 
nightly build.

Mike

André Augusto de Oliveira Aragão wrote:
> HI!
> 
> I think httpclient is having a strange behavior. I´m developing a software
> that, among other things, must make performance measurements on web sites.
> 
> 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. 
> 
> 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´s very
> strange. This time is measured only in the second post interaction, ie, in
> the reply to the 100-continue server response.
> 
> When I use the non-ssl version, the time changes at each try, as expected.
> 
> 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´s 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.
> 
> I´m sending my code, and the log generated for both situations, using the
> https and the http site.
> 
> 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´m wrong.
> 
> I´m using 2.0-alpha3-dev.
> 
> Thanks in advance,
> 
> Andre Augusto
> TCO Celular
> 
> 
> 
> 
> 
> 
> -
> 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]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: POST, Expect-100 and 401 Problem

[McMahon, Joseph]

That works fine as well.

-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 9:47 AM
To: Commons HttpClient Project
Subject: RE: POST, Expect-100 and 401 Problem


Joseph,

I still would like to know what is going on. If it's not a big deal for you,
can you try enabling 'expect: 100-continue' handshake and see if that makes
any difference

Cheers

Oleg

-Original Message-
From: McMahon, Joseph [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 16:42
To: 'Commons HttpClient Project'
Subject: RE: POST, Expect-100 and 401 Problem


The upgrade to the nightly build fixed it.

Thanks,
Joe


-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 9:14 AM
To: Commons HttpClient Project
Subject: RE: POST, Expect-100 and 401 Problem


Joseph,

Can you provide us with the wire log of the HTTP session that reproduces the
problem? 

See HttpClient logging guide for more details on logging:

http://jakarta.apache.org/commons/httpclient/logging.html

I would also advise you to upgrade to the most recent nightly build. Quite a
few things have changed since last 2.0alpha3 release. HttpClient is nearly
ready for the beta-1 release. 

http://jakarta.apache.org/commons/httpclient/downloads.html

Oleg


-Original Message-
From: McMahon, Joseph [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 15:54
To: 'Commons HttpClient Project'
Subject: RE: POST, Expect-100 and 401 Problem


Oleg,

I've created a HttpClient that uses SSL.  When I turn on the debug output I
see the following steps taken:

>From a PostMethod execute:
1.  SSL negotiation starts
2.  Client sends POST (with request body data), but no authentication
header.  This ends with an Expect: 100-continue header
3.  Server responds with a 401 Unauthorized message
4.  SSL Session closes and reopens/negotiates
5.  Client sends POST (without request body), authentication header, a
cookie that was set, and ends it with the Expect: 100-continue header
6.  Server returns 401 (not unauthorized, just empty 401) since there's no
POST request body

Then I tried setting the Preemptive Authentication (guessing that the
Authentication header would be included in the initial POST therefore
bypassing the initial 401 Unauthorized return).  However, I don't see it in
the initial POST.  I also checked with a GET that is working (no body data)
and the authorization negotiation works (that is, GET->401->GET w/
Auth->200) but with Preemptive Authorization set to "true" it does not seem
to insert the Authorization header in the initial GET either.

Thanks,
Joe
 
-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 2:50 AM
To: Commons HttpClient Project
Subject: RE: POST, Expect-100 and 401 Problem


Joe,
Please help me understand what is exactly the problem. The whole idea of
using 'expect: 100-continue' handshake is to avoid sending request body just
to find out that access is not authorized. HttpClient will not send the
request body unless the server acknowledges that it is ok to do so by
responding with status code 100. This is HTTP spec compliant behaviour. If
you do not want 'expect: 100-continue' handshake to take place at all, you
can disable it by invoking ExpectContinueMethod#setUseExpectHeader(boolean)

I hope this helps

Oleg


-Original Message-
From: McMahon, Joseph [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 02:55
To: HTTPCommons (E-mail)
Subject: POST, Expect-100 and 401 Problem


Is there any progress on this problem (it was posted to the newsgroup back
in early Feb.).  I'm running into the same situation where a POST with a
request body is made to an authorizing server.  The initial POST fails for
401, the retry posts all the headers but doesn't appear to repost the
request body data and then terminates returning a 401 error.  If I try to
execute a new POST on that same client connection, it behaves like the
second retry (all headers sent, but no request body).

Any help?

Thanks,
joe


-
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]

-
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]

-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]


---

RE: SSL Performance Problem

[André Augusto de Oliveira Aragão]

Thanks Michael,

I´m trying to send it again, this time as zip file. 

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´t know if it does or not the 100 handshaking - I don't
have the code. Anyway, it´s much faster, and I don´t believe it´s because
it´s 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´s 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:[EMAIL PROTECTED]
Sent: quinta-feira, 3 de abril de 2003 11:39
To: Commons HttpClient Project
Subject: Re: SSL Performance Problem


Hello André,

Unfortunately it seems that the attachments were stipped from your 
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: 
100-continue" header.  Try calling setUseExpectHeader(false) on the post 
method.  I would also suggest using the latest code from CVS or a 
nightly build.

Mike

André Augusto de Oliveira Aragão wrote:
> HI!
> 
> I think httpclient is having a strange behavior. I´m developing a software
> that, among other things, must make performance measurements on web sites.
> 
> 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. 
> 
> 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´s very
> strange. This time is measured only in the second post interaction, ie, in
> the reply to the 100-continue server response.
> 
> When I use the non-ssl version, the time changes at each try, as expected.
> 
> 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´s 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.
> 
> I´m sending my code, and the log generated for both situations, using the
> https and the http site.
> 
> 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´m wrong.
> 
> I´m using 2.0-alpha3-dev.
> 
> Thanks in advance,
> 
> Andre Augusto
> TCO Celular
> 
> 
> 
> 
> 
> 
> -
> 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]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SSL Performance Problem

[Kalnichevski, Oleg]

Mike,
I have no idea. I suppose it has been done on purpose in order to discourage people 
from posting patches to mail lists rather attaching them to bug-reports. Our options 
range from pleading to [EMAIL PROTECTED] to pre-emptively bombing Apache headquarters, 
but something needs to be done about it. I just would like to have Jandalf return 
first. He might have more insights about it

Oleg

-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 16:39
To: Commons HttpClient Project
Subject: Re: SSL Performance Problem



Unfortunately it seems that the attachments were stipped from your 
message.  Jeff, Oleg do you have any idea how we can get this fixed?



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: POST, Expect-100 and 401 Problem

[Kalnichevski, Oleg]

Joseph,

I still would like to know what is going on. If it's not a big deal for you, can you 
try enabling 'expect: 100-continue' handshake and see if that makes any difference

Cheers

Oleg

-Original Message-
From: McMahon, Joseph [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 16:42
To: 'Commons HttpClient Project'
Subject: RE: POST, Expect-100 and 401 Problem


The upgrade to the nightly build fixed it.

Thanks,
Joe


-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 9:14 AM
To: Commons HttpClient Project
Subject: RE: POST, Expect-100 and 401 Problem


Joseph,

Can you provide us with the wire log of the HTTP session that reproduces the
problem? 

See HttpClient logging guide for more details on logging:

http://jakarta.apache.org/commons/httpclient/logging.html

I would also advise you to upgrade to the most recent nightly build. Quite a
few things have changed since last 2.0alpha3 release. HttpClient is nearly
ready for the beta-1 release. 

http://jakarta.apache.org/commons/httpclient/downloads.html

Oleg


-Original Message-
From: McMahon, Joseph [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 15:54
To: 'Commons HttpClient Project'
Subject: RE: POST, Expect-100 and 401 Problem


Oleg,

I've created a HttpClient that uses SSL.  When I turn on the debug output I
see the following steps taken:

>From a PostMethod execute:
1.  SSL negotiation starts
2.  Client sends POST (with request body data), but no authentication
header.  This ends with an Expect: 100-continue header
3.  Server responds with a 401 Unauthorized message
4.  SSL Session closes and reopens/negotiates
5.  Client sends POST (without request body), authentication header, a
cookie that was set, and ends it with the Expect: 100-continue header
6.  Server returns 401 (not unauthorized, just empty 401) since there's no
POST request body

Then I tried setting the Preemptive Authentication (guessing that the
Authentication header would be included in the initial POST therefore
bypassing the initial 401 Unauthorized return).  However, I don't see it in
the initial POST.  I also checked with a GET that is working (no body data)
and the authorization negotiation works (that is, GET->401->GET w/
Auth->200) but with Preemptive Authorization set to "true" it does not seem
to insert the Authorization header in the initial GET either.

Thanks,
Joe
 
-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 2:50 AM
To: Commons HttpClient Project
Subject: RE: POST, Expect-100 and 401 Problem


Joe,
Please help me understand what is exactly the problem. The whole idea of
using 'expect: 100-continue' handshake is to avoid sending request body just
to find out that access is not authorized. HttpClient will not send the
request body unless the server acknowledges that it is ok to do so by
responding with status code 100. This is HTTP spec compliant behaviour. If
you do not want 'expect: 100-continue' handshake to take place at all, you
can disable it by invoking ExpectContinueMethod#setUseExpectHeader(boolean)

I hope this helps

Oleg


-Original Message-
From: McMahon, Joseph [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 02:55
To: HTTPCommons (E-mail)
Subject: POST, Expect-100 and 401 Problem


Is there any progress on this problem (it was posted to the newsgroup back
in early Feb.).  I'm running into the same situation where a POST with a
request body is made to an authorizing server.  The initial POST fails for
401, the retry posts all the headers but doesn't appear to repost the
request body data and then terminates returning a 401 error.  If I try to
execute a new POST on that same client connection, it behaves like the
second retry (all headers sent, but no request body).

Any help?

Thanks,
joe


-
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]

-
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]

-
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]

RE: POST, Expect-100 and 401 Problem

[McMahon, Joseph]

The upgrade to the nightly build fixed it.

Thanks,
Joe


-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 9:14 AM
To: Commons HttpClient Project
Subject: RE: POST, Expect-100 and 401 Problem


Joseph,

Can you provide us with the wire log of the HTTP session that reproduces the
problem? 

See HttpClient logging guide for more details on logging:

http://jakarta.apache.org/commons/httpclient/logging.html

I would also advise you to upgrade to the most recent nightly build. Quite a
few things have changed since last 2.0alpha3 release. HttpClient is nearly
ready for the beta-1 release. 

http://jakarta.apache.org/commons/httpclient/downloads.html

Oleg


-Original Message-
From: McMahon, Joseph [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 15:54
To: 'Commons HttpClient Project'
Subject: RE: POST, Expect-100 and 401 Problem


Oleg,

I've created a HttpClient that uses SSL.  When I turn on the debug output I
see the following steps taken:

>From a PostMethod execute:
1.  SSL negotiation starts
2.  Client sends POST (with request body data), but no authentication
header.  This ends with an Expect: 100-continue header
3.  Server responds with a 401 Unauthorized message
4.  SSL Session closes and reopens/negotiates
5.  Client sends POST (without request body), authentication header, a
cookie that was set, and ends it with the Expect: 100-continue header
6.  Server returns 401 (not unauthorized, just empty 401) since there's no
POST request body

Then I tried setting the Preemptive Authentication (guessing that the
Authentication header would be included in the initial POST therefore
bypassing the initial 401 Unauthorized return).  However, I don't see it in
the initial POST.  I also checked with a GET that is working (no body data)
and the authorization negotiation works (that is, GET->401->GET w/
Auth->200) but with Preemptive Authorization set to "true" it does not seem
to insert the Authorization header in the initial GET either.

Thanks,
Joe
 
-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 2:50 AM
To: Commons HttpClient Project
Subject: RE: POST, Expect-100 and 401 Problem


Joe,
Please help me understand what is exactly the problem. The whole idea of
using 'expect: 100-continue' handshake is to avoid sending request body just
to find out that access is not authorized. HttpClient will not send the
request body unless the server acknowledges that it is ok to do so by
responding with status code 100. This is HTTP spec compliant behaviour. If
you do not want 'expect: 100-continue' handshake to take place at all, you
can disable it by invoking ExpectContinueMethod#setUseExpectHeader(boolean)

I hope this helps

Oleg


-Original Message-
From: McMahon, Joseph [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 02:55
To: HTTPCommons (E-mail)
Subject: POST, Expect-100 and 401 Problem


Is there any progress on this problem (it was posted to the newsgroup back
in early Feb.).  I'm running into the same situation where a POST with a
request body is made to an authorizing server.  The initial POST fails for
401, the retry posts all the headers but doesn't appear to repost the
request body data and then terminates returning a 401 error.  If I try to
execute a new POST on that same client connection, it behaves like the
second retry (all headers sent, but no request body).

Any help?

Thanks,
joe


-
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]

-
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]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SSL Performance Problem

[Michael Becke]

Hello André,

Unfortunately it seems that the attachments were stipped from your 
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: 
100-continue" header.  Try calling setUseExpectHeader(false) on the post 
method.  I would also suggest using the latest code from CVS or a 
nightly build.

Mike

André Augusto de Oliveira Aragão wrote:
HI!

I think httpclient is having a strange behavior. I´m developing a software
that, among other things, must make performance measurements on web sites.
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. 

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´s very
strange. This time is measured only in the second post interaction, ie, in
the reply to the 100-continue server response.
When I use the non-ssl version, the time changes at each try, as expected.

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´s 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.
I´m sending my code, and the log generated for both situations, using the
https and the http site.
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´m wrong.
I´m using 2.0-alpha3-dev.

Thanks in advance,

Andre Augusto
TCO Celular




-
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]

RE: SSL Performance Problem

[Kalnichevski, Oleg]

Andre,

1) SSL
HttpClient is reliant upon Sun's JSSE implementation (alternative SSL implementation 
can also be plugged-in with a bit of coding) to provide SSL transport encryption. From 
the HttpClient's standpoint HTTP does not differ much from HTTPS (if at all) once 
communication socket has been open. You might want to use raw SSL socket in order to 
establish a base-line for your measurements

2) 'Expect: 10-continue' 
RFC2616 does not really provide any guidelines as to when the handshake should or 
should not be used or what is considered to be "normal" or "abnormal" circumstances. 
Any HTTP/1.1 compliant server or proxy MUST be prepared to deal with it at any time. 
Therefore 2.0alpha3 does enable 'Expect: 10-continue' per default. However, the 
handshake has been causing massive problems with HTTP/1.0 proxies, so we have decided 
to disable it per default. The user can still enable/disable 'Expect: 10-continue' 
handshake for any given entity enclosing method.

Cheers

Oleg

-Original Message-
From: André Augusto de Oliveira Aragão
[mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 15:59
To: '[EMAIL PROTECTED]'
Subject: SSL Performance Problem


HI!

I think httpclient is having a strange behavior. I´m developing a software
that, among other things, must make performance measurements on web sites.

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. 

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´s very
strange. This time is measured only in the second post interaction, ie, in
the reply to the 100-continue server response.

When I use the non-ssl version, the time changes at each try, as expected.

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´s 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.

I´m sending my code, and the log generated for both situations, using the
https and the http site.

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´m wrong.

I´m using 2.0-alpha3-dev.

Thanks in advance,

Andre Augusto
TCO Celular



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: POST, Expect-100 and 401 Problem

[Kalnichevski, Oleg]

Joseph,

Can you provide us with the wire log of the HTTP session that reproduces the problem? 

See HttpClient logging guide for more details on logging:

http://jakarta.apache.org/commons/httpclient/logging.html

I would also advise you to upgrade to the most recent nightly build. Quite a few 
things have changed since last 2.0alpha3 release. HttpClient is nearly ready for the 
beta-1 release. 

http://jakarta.apache.org/commons/httpclient/downloads.html

Oleg


-Original Message-
From: McMahon, Joseph [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 15:54
To: 'Commons HttpClient Project'
Subject: RE: POST, Expect-100 and 401 Problem


Oleg,

I've created a HttpClient that uses SSL.  When I turn on the debug output I
see the following steps taken:

>From a PostMethod execute:
1.  SSL negotiation starts
2.  Client sends POST (with request body data), but no authentication
header.  This ends with an Expect: 100-continue header
3.  Server responds with a 401 Unauthorized message
4.  SSL Session closes and reopens/negotiates
5.  Client sends POST (without request body), authentication header, a
cookie that was set, and ends it with the Expect: 100-continue header
6.  Server returns 401 (not unauthorized, just empty 401) since there's no
POST request body

Then I tried setting the Preemptive Authentication (guessing that the
Authentication header would be included in the initial POST therefore
bypassing the initial 401 Unauthorized return).  However, I don't see it in
the initial POST.  I also checked with a GET that is working (no body data)
and the authorization negotiation works (that is, GET->401->GET w/
Auth->200) but with Preemptive Authorization set to "true" it does not seem
to insert the Authorization header in the initial GET either.

Thanks,
Joe
 
-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 2:50 AM
To: Commons HttpClient Project
Subject: RE: POST, Expect-100 and 401 Problem


Joe,
Please help me understand what is exactly the problem. The whole idea of
using 'expect: 100-continue' handshake is to avoid sending request body just
to find out that access is not authorized. HttpClient will not send the
request body unless the server acknowledges that it is ok to do so by
responding with status code 100. This is HTTP spec compliant behaviour. If
you do not want 'expect: 100-continue' handshake to take place at all, you
can disable it by invoking ExpectContinueMethod#setUseExpectHeader(boolean)

I hope this helps

Oleg


-Original Message-
From: McMahon, Joseph [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 02:55
To: HTTPCommons (E-mail)
Subject: POST, Expect-100 and 401 Problem


Is there any progress on this problem (it was posted to the newsgroup back
in early Feb.).  I'm running into the same situation where a POST with a
request body is made to an authorizing server.  The initial POST fails for
401, the retry posts all the headers but doesn't appear to repost the
request body data and then terminates returning a 401 error.  If I try to
execute a new POST on that same client connection, it behaves like the
second retry (all headers sent, but no request body).

Any help?

Thanks,
joe


-
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]

-
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]

SSL Performance Problem

[André Augusto de Oliveira Aragão]

HI!

I think httpclient is having a strange behavior. I´m developing a software
that, among other things, must make performance measurements on web sites.

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. 

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´s very
strange. This time is measured only in the second post interaction, ie, in
the reply to the 100-continue server response.

When I use the non-ssl version, the time changes at each try, as expected.

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´s 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.

I´m sending my code, and the log generated for both situations, using the
https and the http site.

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´m wrong.

I´m using 2.0-alpha3-dev.

Thanks in advance,

Andre Augusto
TCO Celular


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: POST, Expect-100 and 401 Problem

[McMahon, Joseph]

Oleg,

I've created a HttpClient that uses SSL.  When I turn on the debug output I
see the following steps taken:

>From a PostMethod execute:
1.  SSL negotiation starts
2.  Client sends POST (with request body data), but no authentication
header.  This ends with an Expect: 100-continue header
3.  Server responds with a 401 Unauthorized message
4.  SSL Session closes and reopens/negotiates
5.  Client sends POST (without request body), authentication header, a
cookie that was set, and ends it with the Expect: 100-continue header
6.  Server returns 401 (not unauthorized, just empty 401) since there's no
POST request body

Then I tried setting the Preemptive Authentication (guessing that the
Authentication header would be included in the initial POST therefore
bypassing the initial 401 Unauthorized return).  However, I don't see it in
the initial POST.  I also checked with a GET that is working (no body data)
and the authorization negotiation works (that is, GET->401->GET w/
Auth->200) but with Preemptive Authorization set to "true" it does not seem
to insert the Authorization header in the initial GET either.

Thanks,
Joe
 
-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 2:50 AM
To: Commons HttpClient Project
Subject: RE: POST, Expect-100 and 401 Problem


Joe,
Please help me understand what is exactly the problem. The whole idea of
using 'expect: 100-continue' handshake is to avoid sending request body just
to find out that access is not authorized. HttpClient will not send the
request body unless the server acknowledges that it is ok to do so by
responding with status code 100. This is HTTP spec compliant behaviour. If
you do not want 'expect: 100-continue' handshake to take place at all, you
can disable it by invoking ExpectContinueMethod#setUseExpectHeader(boolean)

I hope this helps

Oleg


-Original Message-
From: McMahon, Joseph [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 3. April 2003 02:55
To: HTTPCommons (E-mail)
Subject: POST, Expect-100 and 401 Problem


Is there any progress on this problem (it was posted to the newsgroup back
in early Feb.).  I'm running into the same situation where a POST with a
request body is made to an authorizing server.  The initial POST fails for
401, the retry posts all the headers but doesn't appear to repost the
request body data and then terminates returning a 401 error.  If I try to
execute a new POST on that same client connection, it behaves like the
second retry (all headers sent, but no request body).

Any help?

Thanks,
joe


-
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]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 18355] - HttpState cannot differentiate credentials for different hosts with same Realm names

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18355

HttpState cannot differentiate credentials for different hosts with same Realm names





--- Additional Comments From [EMAIL PROTECTED]  2003-04-03 13:06 ---
Created an attachment (id=5623)
Patch take 3.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 18355] - HttpState cannot differentiate credentials for different hosts with same Realm names

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18355

HttpState cannot differentiate credentials for different hosts with same Realm names





--- Additional Comments From [EMAIL PROTECTED]  2003-04-03 13:06 ---
Mike is of course right, HashMap does use equals as the final comparison 
method (but if o.equals(o1) then o.hashCode() == o1.hashCode() must hold true 
or it will never get to that stage).  Which leaves me baffled as to why the 
test case was failing.  Even more baffling is that when I change the code back 
to what I thought I had before it all works and all test cases pass.  I'll 
attach the latest patch, could someone give it a good testing because I'm 
really quite confused now.

In the mean time, I think I ought to head to bed.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

HashMap does use equals() [was Re: DO NOT REPLY [Bug 18355] - HttpState cannot differentiate credentials for different hosts with sameRealm names]

[Mike Moran]

[EMAIL PROTECTED] wrote:
[ ... ]
The reason is because HashMap only compares the hashCodes of 
the objects and never consults equals. 

[ ... ]

This is not the case. HashMap uses equals() when the hashCode() of two 
objects are the same. If you want good performance it is a good idea to 
have the hashCode() different or at least evenly distributed. However, 
it is not necessary. As a test, try the following code:

import java.util.*;

public class HashMapThing
{
   private static class Key
   {
   private int hashCode;
   private String content;
   private String tag;
   public Key(int hashCode, String content, String tag)
   {
   this.hashCode = hashCode;
   this.content = content;
   this.tag = tag;
   }
   public int hashCode()
   {
   System.out.println("hashCode() called on " + toString());
   return hashCode;
   }
   public boolean equals(Object o)
   {
   System.out.println("equals() called on " + toString()
  + ", " + o.toString());
   if (o instanceof Key) {
   Key other = (Key) o;
   return this.content.equals(other.content);
   }
   else {
   return false;
   }
   }
  
   public String toString()
   {
   return "tag: \"" + tag
   + "\" code: " + hashCode
   + " content: \"" + content + "\"";
   }
   }

   public static void main(String[] args) throws Exception
   {
   Key entryA = new Key(0, "0", "A");
   Key entryB = new Key(0, "0", "B");
   Key entryC = new Key(0, "1", "C");
   System.out.println("Adding entries:");
   Map map = new HashMap();
   System.out.println("A");
   map.put(entryA, "1");
   System.out.println("B");
   map.put(entryB, "2");
   System.out.println("C");
   map.put(entryC, "3");
   System.out.println("\nGetting entries:");
   String out1 = (String) map.get(entryA);
   String out2 = (String) map.get(entryC);
   System.out.println("\nEntries:");
   System.out.println("1: " + out1);
   System.out.println("2: " + out2);
   }
}
--
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 18355] - HttpState cannot differentiate credentials for different hosts with same Realm names

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18355

HttpState cannot differentiate credentials for different hosts with same Realm names





--- Additional Comments From [EMAIL PROTECTED]  2003-04-03 11:16 ---
Adrian, 
I believe replacing HashMap class with ArrayList and implementing our own 
credentials lookup routine would be a better solution. I am afraid there still 
can be situations when credentials may get sent to a server they are not 
intended for (host: '', realm: 'nullwhatver')

Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 18355] - HttpState cannot differentiate credentials for different hosts with same Realm names

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18355

HttpState cannot differentiate credentials for different hosts with same Realm names





--- Additional Comments From [EMAIL PROTECTED]  2003-04-03 10:29 ---
Created an attachment (id=5620)
Patch take 2.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 18355] - HttpState cannot differentiate credentials for different hosts with same Realm names

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18355

HttpState cannot differentiate credentials for different hosts with same Realm names





--- Additional Comments From [EMAIL PROTECTED]  2003-04-03 10:26 ---
Hmm, I believe I've just experienced a solid teaching in basic Java...  There 
were a couple of problems with the class Oleg sent through that took me quite 
a while to work out.  Firstly, when I switched to using it, the credential 
matching routine didn't work.  Turns out that equals will return true in cases 
where the hashCodes don't match (particularly the case where one object has a 
null realm and the other doesn't).  So the comparison logic has to remain in 
HttpState by trying a HttpAuthRealm with host and realm, then with null realm, 
then with null host then with both null.

Secondly, my test case for the spoofed realm exploit Chris Brown pointed out 
still failed.  The reason is because HashMap only compares the hashCodes of 
the objects and never consults equals.  The hashCode did not include the realm 
if it was null (and likewise for the domain).  This then resulted in:

new HttpAuthRealm(null, "admin.apache.org").hashCode() == new HttpAuthRealm
("admin.apache.org", null)

coming down to "admin.apache.org".hashCode() == "admin.apache.org".hashCode() 
which of course returns true.  I've now modified the class to always add the 
host and realm regardless of whether they are null or not.  Thus the 
comparison for the above case becomes:

"nulladmin.appache.org".hashCode() == "admin.apache.orgnull".hashCode() and 
avoids the exploit.  (Notice that titling the realm "admin.apache.orgnull" 
would not help either since it would become "nulladmin.apache.org").

Since the whole process is now effectively back to String comparisons I've 
removed the use of HttpAuthRealm again and all tests still pass (including the 
spoof vulnerability test).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]