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.

Daniel Stenberg wrote:

> On Mon, 21 Mar 2005, Augustus Saunders wrote:
>
> That is correct. But you need to provide username and password, since
> libcurl can't figure that out[*].

Ok, so the same basic framework I have should continue to work:

1) If proxy, set proxy settings
2) Attempt POST
3) while 407, ask for user name/password
     3a) POST again

>> Do I need to set up any of the SSL options?
>
>
> No.

What about for curl_global_init? Do I need to initialize SSL?

>> Right now, I am trapping for 407 responses manually so I can prompt
>> for username/password (is this still necessary, or have you added a
>> callback for this in the last few years?).
>
>
> This is necessary. We did in fact _remove_ a callback for this some
> time ago...

That's interesting. How come?

>> 1) it would be nice if whoever did the MSVC developer distributions
>> would make a full complement of libraries for different linking
>> scenarios. I eventually got everything to compile, but I had to go
>> in and edit the makefiles, which is not comfortable territory for
>> most MSVC types.
>
>
> The makefiles are written to reduce the need for edits as much as
> possible.

Actually, they're pretty good makefiles. Editing them was cake. All I
had to do was change /MD to /MT to match my linker options. As a side
note, I would figure that most people who want a statically linked
libcurl are going to statically link the MS C runtime too.

>> 2) I'm guessing this is a bug, but... if I don't set
>> CURLOPT_WRITEFUNCTION at all, I get lots of sporadic "Error writing
>> body" errors. I created a callback that does nothing, and presto,
>> all the errors went away. Seems like this should be the default
>> behavior.
>
>
> 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? And people wrote applications depending on the fact that
spurious errors get generated sporadically? I mean, why don't you just
say in the docs "CURLOPT_WRITEFUNCTION must be set or you will get Error
writing body errors." Still strikes me as odd.

>
> [*] the upcoming libcurl 7.13.2 supports SSPI which _can_ figure out your
> default windows user and password to use for NTLM authentication
>
That sounds exciting. What's the timeline looking like for 13.2?

Cheers-
Augustus
Received on 2005-03-22