DO NOT REPLY [Bug 18355] - HttpState cannot differentiate credentials for different hosts with same Realm names
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18355. 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]
HashMap does use equals() [was Re: DO NOT REPLY [Bug 18355] - HttpState cannot differentiate credentials for different hosts with sameRealm names]
[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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18355. 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]
DO NOT REPLY [Bug 18355] - HttpState cannot differentiate credentials for different hosts with same Realm names
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18355. 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]
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]
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
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]
RE: SSL Performance Problem
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: 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]
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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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] - To
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]
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 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
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. Correct
Re: SSL Performance Problem
This may be getting fixed soon. See the bugtrack item for Jetty: http://sourceforge.net/tracker/index.php?func=detailaid=699011group_id=732 2atid=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]
