In the direct connection logs, if you look at the first request that returns 401, its response has connection: close, rather strange it worked that way. Anyway, I think this link I posted is the closest I have as a clue...
On 3/15/08, Arno Garrels <[EMAIL PROTECTED]> wrote: > > > I asked the customer to enable > > keep-alive and hope that it will work without any modification. > > Sure, NTLM auth requires Keep-Alive. However, in your log Keep-Alive > is already used correctly, so what will that change? > > -- > Arno Garrels > > Fastream Technologies wrote: > > Hi Guys, > > > > I found this on my research: > > https://issues.apache.org/bugzilla/show_bug.cgi?id=39673 > > > > Seems that NTLM is crap since it assumes statefulness on a stateless > > protocol (HTTP). Shame on M$. I asked the customer to enable > > keep-alive and hope that it will work without any modification. FYI. > > > > Best Regards, > > > > SZ > > > > On 3/15/08, Fastream Technologies <[EMAIL PROTECTED]> wrote: > >> > >> Yes you are probably right--but the code is so simple and I checked > >> the header sent with socketspy and it is the same size (208 bytes > >> after "Authorization: NTLM ") in both direct and non-direct! As I > >> said it is just a tunnel. Is there a way to decrypt the header with > >> some ready tool? I do not want to waste time with complex ntlm code > >> with as you suggested. But will look into structures now.... > >> > >> Regards, > >> > >> SZ > >> > >> > >> On 3/15/08, Arno Garrels <[EMAIL PROTECTED]> wrote: > >>> > >>> Fastream Technologies wrote: > >>>> When I trace the code, it seems that your web server side NTLM code > >>>> is not called at all. > >>> > >>> So, that is your implementation! If you do not call my code it > >>> can hardly be the reason for the problem. > >>> > >>>> It just tunnels the www-authenticate headers > >>>> to/from the web server. > >>> > >>> It's your application that is tunneling. > >>> > >>>> Can you suggest me some URLs so that I can > >>>> read and understand what the eath is wrong with NTLM handshake? > >>> > >>> http://davenport.sourceforge.net/ntlm.html > >>> > >>>> You > >>>> told me all is well in one of your first mails. However, there must > >>>> be something wrong. For example, is the domain info embedded in the > >>>> hashed ntlm handshake? > >>> > >>> If you ever want to know exactly what is included in the NTLM > >>> messages you need to write a parser, basic info from NTLM message > >>> type 2 can be viewed with a function from Francois' unit > >>> OverbyteIcsNtlmMsgs.pas, it also includes the structures and shows > >>> how to parse NTLM messages. > >>> > >>> -- > >>> Arno Garrels > >>> > >>> > >>> -- > >>> To unsubscribe or change your settings for TWSocket mailing list > >>> please goto > >>> http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our > >>> website at http://www.overbyte.be > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be > -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
