hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject RE: Using NTLM auth with expect continue
Date Tue, 15 Apr 2008 17:42:07 GMT

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:olegk@apache.org] 
> 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:olegk@apache.org]
> > 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:olegk@apache.org]
> > > 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:olegk@apache.org]
> > > > 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: 
> > > > httpclient-users-unsubscribe@hc.apache.org
> > > > For additional commands, e-mail: 
> > > > httpclient-users-help@hc.apache.org
> > > >  
> > > > 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: 
> > > > httpclient-users-unsubscribe@hc.apache.org
> > > > For additional commands, e-mail: 
> > > > httpclient-users-help@hc.apache.org
> > > > 
> > > 
> > > 
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > > 
> > > 
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


Mime
View raw message