On Mon, 2008-04-14 at 14:24 -0400, Tony Thompson wrote: > Oleg, > > In my seemingly unending quest to continue torturing myself (and even > you, I guess) with this NTLM auth issue, I found some information that > describes my issue exactly (thanks to Google cache): > > http://64.233.169.104/search?q=cache:LUKVV0AxCHsJ:osdir.com/ml/web.curl. > library/2004-03/msg00432.html+ntlm+http+100+continue&hl=en&ct=clnk&cd=3& > gl=us > > So, I followed the suggestions and I do a probe with a HEAD request when > I have content to post. That works great. The issue that I have is my > application is multi threaded so, if things are busy enough, I may get > one connection when I make the HEAD request then get a different > connection when I do the POST which would put me back to posting on an > unauthenticated connection. Is that possible or is there something in > the connection manager that I am not aware of that will help me out? I > am making the calls back to back, like this: >
No, not with HttpClient 3.1. I am currently working on adding support for stateful connections to HttpClient 4.0 > status = httpClient.executeMethod( hostConfig, head, clientState ); > status = httpClient.executeMethod( hostConfig, method ); > > Is there any way that I can guarantee that I will always be using the > same connection with those two requests? > The only option is to use a separate instance of HttpClient with a simple (non-pooling) connection manager per client / thread of execution. Oleg > Thanks for your help. > Tony > > -----Original Message----- > From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] > Sent: Friday, April 11, 2008 2:07 PM > To: HttpClient User Discussion > Subject: RE: Using NTLM auth with expect continue > > > On Fri, 2008-04-11 at 12:09 -0400, Tony Thompson wrote: > > Well, according to the debug I provided, yes, everything probably > > appears fine. > > Tony, > > I see no reason to not trust the output of the wirelog. > > > But, a packet trace says otherwise. In one of my earlier emails I > > pointed out that a packet trace shows that there is actually extra > > junk sent in the POST. That would explain why the server thinks it is > > > a bad request. Here is the POST packet that I get the 400 response > > for (notice the extra junk at the end "POST /ntlmtest/displa"). > > The content length is set to 21 and there are 21 bytes of junk on the > > end even though we are not supposed to be sending content yet. > > In my opinion the traffic analyzer misinterprets the packets. It > detected the 'content-length: 21' header and mistakenly displayed the > first 21 bytes of the next request head as the content of the previous > one. > > For the love of God, people, do _not_ use NTLM. SSL + Basic is > _infinitely_ more secure. > > Oleg > > > Plus, I > > am not sure why that particular garbage is being sent because that is > > not the content that I am providing anyway (obviously). > > > > Does that help at all? > > > > 0000 50 4f 53 54 20 2f 6e 74 6c 6d 74 65 73 74 2f 64 POST > /ntlmtest/d > > 0010 69 73 70 6c 61 79 66 6f 72 6d 32 2e 61 73 70 20 > isplayform2.asp > > 0020 48 54 54 50 2f 31 2e 31 0d 0a 41 63 63 65 70 74 > HTTP/1.1..Accept > > 0030 3a 20 69 6d 61 67 65 2f 67 69 66 2c 20 69 6d 61 : image/gif, > ima > > 0040 67 65 2f 78 2d 78 62 69 74 6d 61 70 2c 20 69 6d ge/x-xbitmap, > im > > 0050 61 67 65 2f 6a 70 65 67 2c 20 69 6d 61 67 65 2f age/jpeg, > image/ > > 0060 70 6a 70 65 67 2c 20 61 70 70 6c 69 63 61 74 69 pjpeg, > applicati > > 0070 6f 6e 2f 78 2d 73 68 6f 63 6b 77 61 76 65 2d 66 > on/x-shockwave-f > > 0080 6c 61 73 68 2c 20 2a 2f 2a 0d 0a 41 63 63 65 70 lash, > */*..Accep > > 0090 74 2d 4c 61 6e 67 75 61 67 65 3a 20 65 6e 2d 75 t-Language: > en-u > > 00a0 73 0d 0a 55 41 2d 43 50 55 3a 20 78 38 36 0d 0a s..UA-CPU: > x86.. > > 00b0 41 63 63 65 70 74 2d 45 6e 63 6f 64 69 6e 67 3a > Accept-Encoding: > > 00c0 20 67 7a 69 70 2c 20 64 65 66 6c 61 74 65 0d 0a gzip, > deflate.. > > 00d0 55 73 65 72 2d 41 67 65 6e 74 3a 20 4d 6f 7a 69 User-Agent: > Mozi > > 00e0 6c 6c 61 2f 34 2e 30 20 28 63 6f 6d 70 61 74 69 lla/4.0 > (compati > > 00f0 62 6c 65 3b 20 4d 53 49 45 20 37 2e 30 3b 20 57 ble; MSIE 7.0; > W > > 0100 69 6e 64 6f 77 73 20 4e 54 20 35 2e 31 3b 20 2e indows NT 5.1; > . > > 0110 4e 45 54 20 43 4c 52 20 31 2e 31 2e 34 33 32 32 NET CLR > 1.1.4322 > > 0120 29 0d 0a 43 6f 6f 6b 69 65 3a 20 5f 5f 75 74 6d )..Cookie: > __utm > > 0130 61 3d 31 39 32 36 33 35 36 32 34 2e 31 31 35 35 > a=192635624.1155 > > 0140 31 33 37 37 36 32 2e 31 31 39 36 31 37 36 34 36 > 137762.119617646 > > 0150 35 2e 31 32 30 35 35 31 38 34 34 39 2e 31 32 30 > 5.1205518449.120 > > 0160 35 35 32 38 33 31 37 2e 31 37 3b 20 5f 5f 75 74 5528317.17; > __ut > > 0170 6d 7a 3d 31 39 32 36 33 35 36 32 34 2e 31 31 39 > mz=192635624.119 > > 0180 36 31 37 36 34 36 35 2e 31 2e 31 2e 75 74 6d 63 > 6176465.1.1.utmc > > 0190 63 6e 3d 28 64 69 72 65 63 74 29 7c 75 74 6d 63 > cn=(direct)|utmc > > 01a0 73 72 3d 28 64 69 72 65 63 74 29 7c 75 74 6d 63 > sr=(direct)|utmc > > 01b0 6d 64 3d 28 6e 6f 6e 65 29 3b 20 6d 62 6f 78 3d md=(none); > mbox= > > 01c0 50 43 23 31 32 30 33 30 32 30 31 32 32 34 33 30 > PC#1203020122430 > > 01d0 2d 34 38 38 30 39 31 2e 30 30 23 31 32 36 37 32 > -488091.00#12672 > > 01e0 31 35 35 37 36 7c 73 65 73 73 69 6f 6e 23 31 32 > 15576|session#12 > > 01f0 30 34 31 34 30 35 33 38 35 39 33 2d 36 34 39 36 > 04140538593-6496 > > 0200 35 38 23 31 32 30 34 31 34 35 34 33 36 7c 65 64 > 58#1204145436|ed > > 0210 67 65 23 61 70 70 32 2d 70 72 6f 64 33 2e 70 72 > ge#app2-prod3.pr > > 0220 6f 64 33 2e 6f 66 66 65 72 6d 61 74 69 63 61 2e > od3.offermatica. > > 0230 63 6f 6d 2e 31 32 30 34 31 34 33 35 38 32 35 39 > com.120414358259 > > 0240 30 23 31 32 30 34 31 34 35 34 33 37 7c 63 68 65 > 0#1204145437|che > > 0250 63 6b 23 74 72 75 65 23 31 32 30 34 31 34 33 36 > ck#true#12041436 > > 0260 33 36 3b 20 4a 61 6e 75 73 34 4c 65 67 61 63 79 36; > Janus4Legacy > > 0270 3d 4a 61 6e 75 73 34 4c 65 67 61 63 79 3b 20 43 =Janus4Legacy; > C > > 0280 53 74 6f 6e 65 53 65 73 73 69 6f 6e 49 44 3d 6a > StoneSessionID=j > > 0290 72 6f 61 72 67 31 59 62 6e 71 72 65 35 32 36 39 > roarg1Ybnqre5269 > > 02a0 64 35 37 36 21 31 31 39 32 65 39 63 32 34 31 64 > d576!1192e9c241d > > 02b0 21 2d 66 61 31 3b 20 41 53 50 2e 4e 45 54 5f 53 !-fa1; > ASP.NET_S > > 02c0 65 73 73 69 6f 6e 49 64 3d 64 76 65 76 66 76 7a > essionId=dvevfvz > > 02d0 6d 67 69 6a 75 32 6d 32 6d 75 6e 32 67 7a 31 35 > mgiju2m2mun2gz15 > > 02e0 35 3b 20 41 53 50 53 45 53 53 49 4f 4e 49 44 51 5; > ASPSESSIONIDQ > > 02f0 43 43 42 54 51 54 43 3d 48 48 4c 4e 4d 42 50 42 > CCBTQTC=HHLNMBPB > > 0300 49 4a 47 48 50 45 48 4f 4b 44 4e 4c 49 50 45 4a > IJGHPEHOKDNLIPEJ > > 0310 0d 0a 43 61 63 68 65 2d 43 6f 6e 74 72 6f 6c 3a > ..Cache-Control: > > 0320 20 6e 6f 2d 63 61 63 68 65 0d 0a 52 65 66 65 72 > no-cache..Refer > > 0330 65 72 3a 20 68 74 74 70 73 3a 2f 2f 62 62 2e 73 er: > https://bb.s > > 0340 74 6f 6e 65 2d 77 61 72 65 2e 63 6f 6d 2f 6e 74 > tone-ware.com/nt > > 0350 6c 6d 74 65 73 74 2f 66 6f 72 6d 2e 68 74 6d 6c > lmtest/form.html > > 0360 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 > ..Content-Type: > > 0370 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 2d 77 77 > application/x-ww > > 0380 77 2d 66 6f 72 6d 2d 75 72 6c 65 6e 63 6f 64 65 > w-form-urlencode > > 0390 64 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 > d..Content-Lengt > > 03a0 68 3a 20 32 31 0d 0a 48 6f 73 74 3a 20 6d 73 73 h: 21..Host: > mss > > 03b0 62 30 31 2e 73 74 6f 6e 65 2d 77 61 72 65 2e 63 > b01.stone-ware.c > > 03c0 6f 6d 0d 0a 45 78 70 65 63 74 3a 20 31 30 30 2d om..Expect: > 100- > > 03d0 63 6f 6e 74 69 6e 75 65 0d 0a 0d 0a 50 4f 53 54 > continue....POST > > 03e0 20 2f 6e 74 6c 6d 74 65 73 74 2f 64 69 73 70 6c > /ntlmtest/displ > > 03f0 61 a > > > > -----Original Message----- > > From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] > > Sent: Friday, April 11, 2008 3:08 AM > > To: HttpClient User Discussion > > Subject: RE: Using NTLM auth with expect continue > > > > > > On Thu, 2008-04-10 at 18:57 -0400, Tony Thompson wrote: > > > The request URL is perfectly valid. > > > > The response from the server seems to suggest otherwise > > > > > As I stated in an earlier email, I can do this same exact thing > > > WITHOUT forcing a connection closed before the POST and it works > > > fine. If I force the connection closed before the POST so that the > > > HTTP client has to renegotiate the NTLM > > auth, it fails. > > > In my test, I am forcing the connection closed so that HTTPClient > > > has to open a new connection (and authenticate it) for the POST. I > > > need to get the expect continue handshake to work before I post the > > > data because I don't want to buffer the content since it has to be > > > posted several times during the handshake. > > > > > > > I understand what you are trying to do, but I see nothing wrong with > > the requests generated by HttpClient > > > > Oleg > > > > > Make sense? > > > Tony > > > > > > -----Original Message----- > > > From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, April 10, 2008 5:46 PM > > > To: HttpClient User Discussion > > > Subject: RE: Using NTLM auth with expect continue > > > > > > > > > On Thu, 2008-04-10 at 17:19 -0400, Tony Thompson wrote: > > > > Hopefully this has what you need: > > > > > > > > > > ... > > > > > > > DEBUG (04/10) 17:10:58 [httpclient.wire.content]: << "<h1>Bad > > > > Request (Invalid URL)</h1>" > > > > > > ... > > > > > > This seems to have nothing to do with NTLM authentication. The > > > request > > > > > appears to have been rejected due to the invalid request URL. > > > > > > Hope this helps > > > > > > Oleg > > > > > > > > > > -----Original Message----- > > > > From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] > > > > Sent: Thursday, April 10, 2008 2:52 PM > > > > To: HttpClient User Discussion > > > > Subject: RE: Using NTLM auth with expect continue > > > > > > > > > > > > On Thu, 2008-04-10 at 09:59 -0400, Tony Thompson wrote: > > > > > I have debug enabled for org.apache.commons.httpclient so, I am > > > > > not sure why nothing comes out. Is there a specific class I > > > > > should turn > > > > > > > > on debug for that would give you the info you need? > > > > > > > > > > > > > Tony > > > > > > > > I will not be able to be of any meaningful help unless you manage > > > > to > > > > > > produce a _complete_ session log that also includes context > > > > information (especially that about connections being open and > > > > closed, and credentials management) > > > > > > > > http://hc.apache.org/httpclient-3.x/logging.html > > > > > > > > Oleg > > > > > > > > > Maybe my last message wasn't clear enough on the POST without > > > > > NTLM > > > > > > > credentials. I tell HTTPClient to execute a method without > > > > > providing the credentials, I detect the 401 and then I start > > > > > over and POST again > > > > > > > > > with the credentials. I will probably change it at some point > > > > > so that > > > > > > > > > I preemptively provide the credentials but at this point it is > > > > irrelevant. > > > > > The POST fails if the credentials are there or not. Here is the > > > > > > same limited trace of the request with the NTLM header. > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > -- > > > > - To unsubscribe, e-mail: > > > > [EMAIL PROTECTED] > > > > For additional commands, e-mail: > > > > [EMAIL PROTECTED] > > > > > > > > This message (and any associated files) is intended only for the > > > > use > > > > > > of the individual or entity to which it is addressed and may > > > > contain > > > > > > information that is confidential, subject to copyright or > > > > constitutes a trade secret. If you are not the intended recipient > > > > you are hereby notified that any dissemination, copying or > > > > distribution of this message, or files associated with this > > > > message, > > > > > > is strictly prohibited. If you have received this message in > > > > error, please notify us immediately by replying to the message and > > > > > deleting > > > > > > it from your computer. Messages sent to and from Stoneware, Inc. > > > > may be monitored. > > > > > > > > ------------------------------------------------------------------ > > > > -- > > > > - 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] > > > --------------------------------------------------------------------- > 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]
