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