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
