2012/4/17 Daniel Stenberg wrote:

>  CURLAUTH_BASIC | CURLAUTH_ONLY
>
> 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.

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.

Just a couple of subtle details without much implications.

> We should probably assume that there by now is an application or two that
> use it, so we should try to fix it in a way that is least likely to break
> existing apps.

Probably...

#define CURLAUTH_BASIC (1U<<0)
#define CURLAUTH_DIGEST (1U<<1)
[...]
#define CURLAUTH_ONLY (1U<<31)

Unless someone speaks in favour of...

#define CURLAUTH_ONLY (1<<30)

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

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html