Well, according to the debug I provided, yes, everything probably appears fine. 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. 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]
