Fastream Technologies wrote: > In the direct connection logs, if you look at the first request that > returns 401, its response has connection: close,
That's totally ok since at that time the auth-type is not yet negotiated. However when the NTLM message type 1 is sent from the client to the server Keep-Alive must be ON. -- Arno Garrels 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
