Ok, I've figured out basically what's happening. If you are POSTing
form data, them libcurl does not complete the NTLM handshake. It sends
the first "Proxy-Authentication: NTLM data" header, the proxy responds
with "Access Denied" and provides the next step in the NTLM handshake,
but the final "Proxy-Authentication: NTLM data" response from curl still
has the original data--it doesn't finish the handshake. And so it goes
into an infinite loop posting the same auth code over and over. If you
use HTTP GET, it's all fine. I'm going to try issuing a spurious GET
just to let the authentication work, and see if I can follow it up with
POSTs. I'm getting lost tracking through the libcurl code figuring out
why POST is different than GET in this respect.

Also, I intend to figure out why CURLAUTH_ANY doesn't seem to work; I
found the place in the code where that get's checked. Thanks-

Augustus

Augustus Saunders wrote:

>Ok, I've got a little bit more information now. I've
>actually got a MS ISA server set up now to test against. I
>am using 7.13.1 and am having two problems:
>
>1) When using "CURLAUTH_ANY" value for CURLOPT_PROXYAUTH, no
>proxy-authorization headers are generated in the output.
>2) When I manually set the proxy authorization to be NTLM,
>then it generates what appears to be an OK
>"proxy-authorization: NTLM blahblah" header in the output,
>but the proxy server responds with "Authorization denied."
>Apparently, this sends libcurl into some infinite loop, as
>it tries to send it over and over again (without ever
>returning from curl_easy_perform).
>
>I checked the curl executable I have under Cygwin, which is
>7.11.1, and it seemed to negotatiate the NTLM correctly when
>given the --proxy-ntlm option (I wasn't sure how to tell the
>command line program to guess which auth mode to use).
>
>Problem #1 is most likely user error on my part, although
>your emails indicate that I'm doing the right steps. The
>Authorization Denied thing is probably an OpenSSL problem,
>right? The infinite loop thing is probably a bug ;)
>
>I built with OpenSSL 0.9.7e, and I did use the ASM build. I
>noticed that they *just* released 7f, maybe I should try it?
>
>Any thoughts on how to further track this down would be most
>appreciated. Thanks in advance-
>
>Augustus
>
>PS I was curious about the removal of the password callback
>and looked at the email. Not sure I follow the reasoning
>(that's ok, no need to explain again), but it looked like
>technical reasons. I appologize for not following up on my
>Sept 2002 offer for a patch to make a proxy-auth callback,
>but hopefully anybody that reimplements the callback will
>take care of proxy's while they're at it.
>
>On Tue, 22 Mar 2005 10:09:46 +0100 (CET)
> Daniel Stenberg <daniel-curl_at_haxx.se> wrote:
>
>
>>On Mon, 21 Mar 2005, Augustus Saunders wrote:
>>
>>
>>
>>>Thanks for the reply. Overall, it sounds like things
>>>
>>>
>>should "just work."
>>
>>
>>>I'm going to try and get better outgoing header
>>>
>>>
>>captures using the
>>
>>
>>>CURL_DEBUG options to try and figure out why it's not.
>>>
>>>
>>You should also make sure you use a recent libcurl
>>version since we've been
>>fixing bugs in this area recently.
>>
>>
>>
>>>1) If proxy, set proxy settings
>>>2) Attempt POST
>>>3) while 407, ask for user name/password
>>> 3a) POST again
>>>
>>>
>>Yes, if you don't have the name/password already I guess
>>this is how you
>>should do it.
>>
>>
>>
>>>>>Do I need to set up any of the SSL options?
>>>>>
>>>>>
>>>>No.
>>>>
>>>>
>>>What about for curl_global_init? Do I need to
>>>
>>>
>>initialize SSL?
>>
>>No, you don't. NTLM doesn't really use SSL, it just uses
>>some crypto functions
>>(for DES and MD4) that are present in one the SSL
>>libraries. You don't have to
>>init anything to use them.
>>
>>
>>
>>>>This is necessary. We did in fact _remove_ a callback
>>>>
>>>>
>>for this some time
>>
>>
>>>>ago...
>>>>
>>>>
>>>That's interesting. How come?
>>>
>>>
>>The reasoning was posted to this list in October 2003:
>>
>> http://curl.haxx.se/mail/lib-2003-10/0100.html
>>
>>
>>
>>>>The default behavior was set years ago and I've not
>>>>
>>>>
>>yet seen any good
>>
>>
>>>>reason to break backwards compatibility in that
>>>>
>>>>
>>aspect. Very few apps
>>
>>
>>>>actually need or use the default behaviour anyway.
>>>>
>>>>
>>>I don't understand. The default behavior *intentially*
>>>
>>>
>>generates errors?
>>
>>No. You need to widen your perspective. It doesn't
>>generate errors by default
>>on most platforms I know of (and curl the command line
>>tool assumes and uses
>>the default behaviour on quite a few platforms). I'm not
>>even sure exactly why
>>you get these errors. But then I don't do much libcurl on
>>windows. Possibly it
>>happens because you don't have a stdout?
>>
>>
>>
>>>And people wrote applications depending on the fact
>>>
>>>
>>that spurious errors get
>>
>>
>>>generated sporadically?
>>>
>>>
>>People who use and depend on the default behavior don't
>>get these errors.
>>
>>
>>
>>>I mean, why don't you just say in the docs
>>>
>>>
>>"CURLOPT_WRITEFUNCTION must be
>>
>>
>>>set or you will get Error writing body errors."
>>>
>>>
>>Because it isn't true to a majority.
>>
>>
>>
>>>That sounds exciting. What's the timeline looking like
>>>
>>>
>>for 13.2?
>>
>>I'd say within a few weeks. I have a larger change
>>pending, and I'd prefer to
>>have 7.13.2 released before I commit this larger work...
>>
>>You can always get a recent snapshot or CVS version and
>>try it out before
>>release to see if it solves your problems...
>>
>>--
>> Daniel Stenberg -- http://curl.haxx.se --
>>http://daniel.haxx.se
>> Commercial curl and libcurl Technical Support:
>>http://haxx.se/curl.html
>>
>>
>
>
>
>
Received on 2005-03-24