Re: http.c (curl_easy_setopt and CURLAUTH_ANY)
- From
Daniel Stenberg <daniel@haxx.se>
- Date
- Aug 28, 2015, 06:34 UTC
- Message-ID
- <alpine.DEB.2.11.1508280831230.20243@tvnag.unkk.fr>
- In-Reply-To
- <CAF0pADEsO0y_6wcx-xNwRqjauJmMcQ8mUmbUbbWCBrK2gQ1quA@mail.gmail.com>
On Fri, 28 Aug 2015, Stephen Kazakoff wrote:
Show 12 quoted lines
> From: > curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY); > > To: > curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_BASIC | CURLAUTH_NTLM); > > I did however find the CURL documentation > (https://secure.php.net/manual/en/function.curl-setopt.php) slightly > conflicting. On one hand, "CURLAUTH_ANY" is effectively the same as passing > "CURLAUTH_BASIC | CURLAUTH_NTLM". But the documentation for > "CURLOPT_PROXYAUTH" says that only "CURLAUTH_BASIC" and "CURLAUTH_NTLM" are > currently supported. By that, I'm assuming "CURLAUTH_ANY" is not supported.
That would rather indicate a problem somewhere else.
CURLAUTH_ANY is just a convenience define that sets a bunch of bits at once, and libcurl will discard bits you'd set for auth methods your libcurl hasn't been built to deal with anyway. Thus, the above two lines should result in (almost) exactly the same behavior from libcurl's point of view.
The fact that they actually make a difference is probably because ANY then enables a third authentication method that perhaps your server doesn't like? Or is it a libcurl bug?
Hard to tell without more info, including libcurl version. But no, the above suggested change doesn't really make much sense for the general population.
-- / daniel.haxx.se