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]