On Tue, Mar 22, 2005 at 09:34:56PM +0100, Daniel Stenberg wrote:
> The main reason would be that for most auth methods you provide a
> user+password that get used. For GSS you can provide anything and it won't
> ever be used. For NTLM when SSPI-enable, you must set a blank user+password
> to get it to use the user+password from the system, or you set a non-blank
> set to make libcurl use that.
>
> These special-cases are what concern me. Not a lot, but some.

How about three new options:
        CURLOPT_USERNAME
        CURLOPT_PASSWORD
        CURLOPT_ENABLE_AUTH

New code would have to set CURLOPT_ENABLE_AUTH to have any authentication.
Then CURLOPT_USERPWD would be deprecated and rewritten internally to do
CURLOPT_ENABLE_AUTH, CURLOPT_USERNAME and CURLOPT_PASSWORD.
CURLOPT_ENABLE_AUTH could even be a renamed and generalized CURLOPT_HTTPAUTH.

This would be backwards-compatible yet give a cleaner interface going forward
for new apps. Am I missing anything?

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved