On Tue, 17 Apr 2012, Yang Tse wrote:

>> It would cause libcurl to try without auth and then only allow Basic to be
>> used. Therefore, the CURLAUTH_ONLY bit is never explicitly checked for or
>> used by libcurl code.
>
> Ok. Although url.c:1485 provides a couple of 'features' that I'm not sure if
> they are fully intended.

Oh right...

> 1) Lets suppose that libcurl is built without NTLM support, and that
> CURLAUTH_NTLM is set along with CURLAUTH_ONLY. In this case
> curl_easy_setopt() does not fail with CURLE_NOT_BUILT_IN and using program
> would not detect that libcurl doesn't support CURLAUTH_NTLM. Same for other
> CURLAUTH_* that depend on support being built-in or not.
>
> As a workaround, program could first call curl_easy_setopt() without
> CURLAUTH_ONLY and afterwards issue same flags along with CURLAUTH_ONLY.

> 2) Would it be worth to reject CURLAUTH_ONLY given alone? In this case it
> works as if CURLAUTH_NONE had been used.

That's indeed unintentional. That check really needs to be enhanced. Don't we
also have something similar elsewhere? Yes, only CURLAUTH_ONLY is not really a
valid bitmask.

> #define CURLAUTH_ONLY (1U<<31)

I prefer that one.

> And directly related with all this... CURLAUTH_ANY and CURLAUTH_ANYSAFE
> current definitions happen to include the CURLAUTH_ONLY bit.

Right, but I can't see any harm in that. Can you?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html