2009/8/28 Daniel Stenberg <daniel_at_haxx.se>

> On Fri, 21 Aug 2009, Paul Harris wrote:
>
> * the proxy responds asking for NTLM auth, and my app never sends it,
>> instead it continues to send the original POST.
>>
>
> Do you have NTLM explicitly enabled, or do you allow several auth types?
>

several

>
>
> * the proxy responds asking for NTLM, my app starts to send out the
>> header,
>> and ... nothing happens.
>>
>
> When you said "my app starts to send" you mean that libcurl sends the
> header? If so, does it send the entire request or just "the header"? If the
> latter, what is "the header" in this context?
>

i see in the MS Network Monitor that it sends "the header", which seems to
be somehow distinct from "the payload", which would follow if it were a
successful send. also see below, "Send header". as to what the header is,
its whatever is required to POST HTTP.

>
>
> * it tried to post earlier, saw the NTLM request, and now ... *
>> CURL: INFO Re-using existing connection! (#0) with host 10.0.250.1
>> CURL: INFO Connected to 10.0.250.1 (10.0.250.1) port 80 (#0)
>> CURL: INFO Proxy auth using NTLM with user 'username'
>> CURL: => Send header
>> * nothing happens for a minute, at which point my app gives up *
>>
>
> Did the previous request on that connection work fine?
>

yes.

>
>
> I use multihandles so that I can cancel the upload when I want, but I
>> always open and close fresh handles whenever I do something with curl.
>>
>
> Fresh handles don't prevent connection re-uses. libcurl keeps the
> connection pool within the multi handle, so you can't "escape" connection
> re-use by doing new easy handles to use.
>

i rebuild both the multi and the easy handles. is that enough? in tear
down whatever i construct, so in between uploads, the only thing that
survives is whatever the curl global init stuff creates.

i don't upload often, so speed is not the issue.

>
>
> What can I try to do ? I wouldn't mind spending a little effort debugging
>> this issue, although I'm not able to do a lot on the computer in question.
>>
>
> Well, I would like to see a repeatable behavior. Exactly what is done to
> make the problem trigger. Then I would like to attempt to repeat such
> behavior with curl's test suite or possibly a proxy/server that is
> accessible to me.
>

the proxy is part of a huge company with large, slow it support which i am
not a part of, so getting access is out of the question. however, if we can
use the test suite on the client side, and connect to a server on the other
side (either mine, i can add cgi responders or whatever ... or yours), then
we might have a chance.

>
> In regards to the debugging this, it's just normal debugging: figure out
> what it does when it "hangs" and then backtrack to why it comes to that
> situation and what it should do instead to not end up there...
>

well, i first concern is the NTLM, because sometimes i see the pattern (in
ms net monitor) that is something like this (sorry off top of the head):
-> send header
<- ntlm auth needed
-> send header+ntlm
maybe ok in here?
-> send payload
<- ok
thats fine

and then,
-> send header
<- ntlm auth needed
-> send payload (!)
<- ntlm auth needed

um and then someother stuff. really i'm sorry but i wanted to respond
before the weekend started. my question is, do you think the NTLM
component could be the likely source of the problem? what is this header
and payload stuff? should the payload be sent before it gets an ok for the
header? or will curl try and send header and payload, unless it is
interrupted with a not-ok response?

thanks,
Paul
Received on 2009-08-28