Re: Repeated calls to ares_init when using c-ares
On Tue, 28 Jan 2020, Jeff Mears via curl-library wrote: Is there a way for libcurl to use one instance of c-ares, rather than trying to create one for every curl_easy_init? There isn't any such right now, and doing one globally would be tricky while mainaining thread safety. I can think of two ways to provide the feature: 1. It would perhaps make sense to add that ability to the share interface and allow applications to explictly specify which handles should share the c-ares instance? 2. A simpler method would possibly be to use a single c-ares "channel" for a whole multi handle, as then you would just make sure to keep the multi handle around when doing multiple transfers and c-ares wouldn't have to re-init. -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Static libcurl on macOS with SPNEGO AND https-proxy
On Wed, 29 Jan 2020, Kay Jurkuhn via curl-library wrote: SPNEGO works fine. But if I try to access a reverse https proxy, libcurl tells me that it is not built with the https proxy feature. curl built to use Secure Transport does not support HTTPS proxy. Your command line didn't switch off OpenSSL from the build, so did you build curl with the ability to use both TLS libraries perhaps? Although curl-config --features tells otherwise. If you included OpenSSL then it can. I also tried to built it with OpenSSL 1.1.1d, with this I can access a https proxy. But it doesn't use the macOS keychain. And that a "no-go" for my project. Then you seem to sit in a tight mutually exclusive situation. Secure Transport without HTTPS support or OpenSSL without macOS keychain support. As I understand it, Apple has implemented their own TSL version and is not using OpenSSL any more. Apple once used OpenSSL. Then Apple implemented Secure Transport, used it for a while (and shipped curl built to use it) and then basically abandoned it (but it is still present). Now they have a new TLS framework (which curl hasn't been adapted for), they ship curl built with libressl and include boringssl in macOS (for what purpose I don't know). So yeah, they're basically all over the map. (Disclaimer: I have no insights in their TLS story, I might have grossly misunderstood the details.) -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Static libcurl on macOS with SPNEGO AND https-proxy
Hi, I'm trying to build libcurl (7.67) on macOS 10.14 as a static lib. Beside ssl I would like to include the SPNEGO feature AND https-proxy. Also I want libcurl to use the macOS keychain. So I tried this configuration //- export CFLAGS="-mmacosx-version-min=10.13" ./configure -prefix=/Dev/curl-7.67.0/Builds --with-darwinssl=/System/Library/Frameworks/Sercurity.framework --with-gssapi=/System/Library/Frameworks/Kerberos.framework --with-ca-fallback --without-ca-bundle --enable-ipv6 --enable-static --disable-shared //- Include libcurl in my project //- "Dev/SDKs/curl/7.67.0/macOS/lib/libcurl.a" -framework CoreFoundation -framework Security -framework Kerberos -framework LDAP -L"/opt/local/lib" -lssl -lcrypto -lgssapi_krb5 -lresolv -lldap -lz //- SPNEGO works fine. But if I try to access a reverse https proxy, libcurl tells me that it is not built with the https proxy feature. Although curl-config --features tells otherwise. I also tried to built it with OpenSSL 1.1.1d, with this I can access a https proxy. But it doesn't use the macOS keychain. And that a "no-go" for my project. As I understand it, Apple has implemented their own TSL version and is not using OpenSSL any more. The still installed OpenSSL is version 1.0.2a. May be too old. Now my question is: Am I overlooking something? What do I have to do to build a static libcurl version on macOS with the features SPNEGO and https-proxy? Cheers Kay --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: 7.58.0 curl_global_sslset returns CURLSSLSET_TOO_LATE
On 1/28/2020 8:09 PM, Pawel Veselov wrote:
On Wed, Jan 29, 2020 at 1:09 AM Ray Satiro wrote:
On 1/28/2020 5:13 PM, Pawel Veselov wrote:
On Tue, Jan 28, 2020 at 10:24 PM Ray Satiro via
curl-library wrote:
On 1/28/2020 1:17 PM, Pawel Veselov via curl-library wrote:
I have a simple prologue code in my program to select SSL backend. It
works on relatively
recent versions (e.g. 7.65), but specifically on 7.58 ("latest" for
Ubuntu 18),
curl_global_sslset() returns CURLSSLSET_TOO_LATE.
I thought somebody else may be calling init function, but I can see
from the source code
that it simply returns TOO_LATE if there are no multiple SSL backends,
and if ID
doesn't match the ID of the backend that was actually compiled in.
Could you please save me some investigative time and let me know in
which version
was this changed so that calling this with without IDs returns list of
available backends even
in case of single backend?
sslset also returns too late if it has been called after global init.
global init hasn't been called.
How are you calling it, with name or id?
I just want the list, so I pass id of -1 and name of 0.
There was an issue when id was
set to -1 that was fixed [1] a year ago. Also there was an improvement
in 7.60 to return the backends even if too late [2]. The change is
documented you could test for it like this:
if(rc != CURLSSLSET_OK) {
curl_version_info_data *verinfo = curl_version_info(CURLVERSION_NOW);
if(verinfo->version_num >= CURL_VERSION_BITS(7,60,0)) {
/* backend list available even if CURLSSLSET_TOO_LATE */
}
}
Ah, I see. The bone that I have to pick with this is that return of
TOO_LATE can happen because either global init was called, or
because there is only one backend (and I didn't guess right), and
I can't really tell the difference.
The whole deal here is that I want to prevent getting libcurl with one
backend in particular. I guess my logic should be:
* call sslset with -1/NULL. If that gives me a list of backends,
pick the one that I want, and call sslset again, and see if it worked
* If there was no list of backends, try to call with the bad
backend ID, and see if then it succeeds. If it does, then I have
a backend I don't want
To be clear it is supposed to work as it is documented [1].
If it does not work that way (aside from that known bug in early versions)
please let us know.
I don't know why you would try to set the backend you don't want.
I was trying to figure out a good way to workaround #3346
for versions that still have it.
Do you mean you need to know if a particular backend is in use?
Yes. If a particular backend is in use, I want to not let my
application continue,
and if I have a choice - pick any other backend except for that one I dislike
and NONE:)
We don't have a curl_global_sslget [2].
That's a pity. But even if it was added now, I would still need to make the
logic work for earlier versions (reasonably, but I need, for example,
to support Ubuntu 16 that uses 7.47).
[1]:https://curl.haxx.se/libcurl/c/curl_global_sslset.html
[2]:https://github.com/curl/curl/pull/2063
Thank you for your help!
Well the workaround I mentioned in that bug does work, you can see how
we used it [1] in the curl tool. Basically after curl has initialized
you can call curl_easy_init [2] to create an easy handle (note if you do
this before initializing curl, it will call initialization for you) and
then get the backend of that handle. Currently the backend is set
globally and can't be changed but it could be improved at some point to
allow it per handle, which I think is part of why I got a lukewarm
reception to add a global way to get the backend.
In your case you would use CURLINFO_TLS_SESSION [4] the predecessor to
CURLINFO_TLS_SSL_PTR [3]. Although it is not documented (I will change
this) only since 7.45.0 it will always return the backend in use [5]. So
you could do it like this:
/* initialize curl before calling curl_version_info */
if(!(verinfo->features & CURL_VERSION_SSL)) {
problem = true; /* may happen */
}
else if(verinfo->version_num < CURL_VERSION_BITS(7,45,0)) {
/* no multiple ssl backends and no ssl backend constants */
sslver = duplowercase(verinfo->ssl_version);
if(!sslver) /* shouldn't happen */
abort();
if(strstr(sslver, "openssl")) /* may happen */
problem = true;
free(sslver);
else {
CURL *curltls = curl_easy_init();
struct curl_tlssessioninfo *tbi = NULL;
CURLcode rc = curl_easy_getinfo(curltls, CURLINFO_TLS_SESSION, );
if(rc || tbi->backend == CURLSSLBACKEND_NONE) { /* shouldn't happen */
curl_easy_cleanup(curltls);
abort();
}
if(tbi->backend == CURLSSLBACKEND_OPENSSL) /* may happen */
problem = true;
curl_easy_cleanup(curltls);
}
Working with the string compare has some caveats because like in the
case of openssl it doesn't the forks. For example you may have libressl
or boringssl which are forks of openssl. Or how wolfssl was
Re: 7.58.0 curl_global_sslset returns CURLSSLSET_TOO_LATE
On Wed, Jan 29, 2020 at 1:09 AM Ray Satiro wrote:
>
> On 1/28/2020 5:13 PM, Pawel Veselov wrote:
>
> On Tue, Jan 28, 2020 at 10:24 PM Ray Satiro via curl-library
> wrote:
>>
>> On 1/28/2020 1:17 PM, Pawel Veselov via curl-library wrote:
>> >
>> > I have a simple prologue code in my program to select SSL backend. It
>> > works on relatively
>> > recent versions (e.g. 7.65), but specifically on 7.58 ("latest" for
>> > Ubuntu 18),
>> > curl_global_sslset() returns CURLSSLSET_TOO_LATE.
>> > I thought somebody else may be calling init function, but I can see
>> > from the source code
>> > that it simply returns TOO_LATE if there are no multiple SSL backends,
>> > and if ID
>> > doesn't match the ID of the backend that was actually compiled in.
>> >
>> > Could you please save me some investigative time and let me know in
>> > which version
>> > was this changed so that calling this with without IDs returns list of
>> > available backends even
>> > in case of single backend?
>>
>>
>> sslset also returns too late if it has been called after global init.
>
>
> global init hasn't been called.
>
>>
>> How are you calling it, with name or id?
>
>
> I just want the list, so I pass id of -1 and name of 0.
>
>>
>> There was an issue when id was
>> set to -1 that was fixed [1] a year ago. Also there was an improvement
>> in 7.60 to return the backends even if too late [2]. The change is
>> documented you could test for it like this:
>>
>>if(rc != CURLSSLSET_OK) {
>> curl_version_info_data *verinfo = curl_version_info(CURLVERSION_NOW);
>> if(verinfo->version_num >= CURL_VERSION_BITS(7,60,0)) {
>>/* backend list available even if CURLSSLSET_TOO_LATE */
>> }
>>}
>
>
> Ah, I see. The bone that I have to pick with this is that return of
> TOO_LATE can happen because either global init was called, or
> because there is only one backend (and I didn't guess right), and
> I can't really tell the difference.
>
> The whole deal here is that I want to prevent getting libcurl with one
> backend in particular. I guess my logic should be:
> * call sslset with -1/NULL. If that gives me a list of backends,
> pick the one that I want, and call sslset again, and see if it worked
> * If there was no list of backends, try to call with the bad
> backend ID, and see if then it succeeds. If it does, then I have
> a backend I don't want
>
>
> To be clear it is supposed to work as it is documented [1].
> If it does not work that way (aside from that known bug in early versions)
> please let us know.
> I don't know why you would try to set the backend you don't want.
I was trying to figure out a good way to workaround #3346
for versions that still have it.
> Do you mean you need to know if a particular backend is in use?
Yes. If a particular backend is in use, I want to not let my
application continue,
and if I have a choice - pick any other backend except for that one I dislike
and NONE :)
> We don't have a curl_global_sslget [2].
That's a pity. But even if it was added now, I would still need to make the
logic work for earlier versions (reasonably, but I need, for example,
to support Ubuntu 16 that uses 7.47).
> [1]: https://curl.haxx.se/libcurl/c/curl_global_sslset.html
> [2]: https://github.com/curl/curl/pull/2063
Thank you for your help!
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: 7.58.0 curl_global_sslset returns CURLSSLSET_TOO_LATE
On 1/28/2020 5:13 PM, Pawel Veselov wrote:
On Tue, Jan 28, 2020 at 10:24 PM Ray Satiro via curl-library
mailto:curl-library@cool.haxx.se>> wrote:
On 1/28/2020 1:17 PM, Pawel Veselov via curl-library wrote:
>
> I have a simple prologue code in my program to select SSL
backend. It
> works on relatively
> recent versions (e.g. 7.65), but specifically on 7.58 ("latest" for
> Ubuntu 18),
> curl_global_sslset() returns CURLSSLSET_TOO_LATE.
> I thought somebody else may be calling init function, but I can see
> from the source code
> that it simply returns TOO_LATE if there are no multiple SSL
backends,
> and if ID
> doesn't match the ID of the backend that was actually compiled in.
>
> Could you please save me some investigative time and let me know in
> which version
> was this changed so that calling this with without IDs returns
list of
> available backends even
> in case of single backend?
sslset also returns too late if it has been called after global init.
global init hasn't been called.
How are you calling it, with name or id?
I just want the list, so I pass id of -1 and name of 0.
There was an issue when id was
set to -1 that was fixed [1] a year ago. Also there was an
improvement
in 7.60 to return the backends even if too late [2]. The change is
documented you could test for it like this:
if(rc != CURLSSLSET_OK) {
curl_version_info_data *verinfo =
curl_version_info(CURLVERSION_NOW);
if(verinfo->version_num >= CURL_VERSION_BITS(7,60,0)) {
/* backend list available even if CURLSSLSET_TOO_LATE */
}
}
Ah, I see. The bone that I have to pick with this is that return of
TOO_LATE can happen because either global init was called, or
because there is only one backend (and I didn't guess right), and
I can't really tell the difference.
The whole deal here is that I want to prevent getting libcurl with one
backend in particular. I guess my logic should be:
* call sslset with -1/NULL. If that gives me a list of backends,
pick the one that I want, and call sslset again, and see if it worked
* If there was no list of backends, try to call with the bad
backend ID, and see if then it succeeds. If it does, then I have
a backend I don't want
To be clear it is supposed to work as it is documented [1]. If it does
not work that way (aside from that known bug in early versions) please
let us know. I don't know why you would try to set the backend you don't
want. Do you mean you need to know if a particular backend is in use? We
don't have a curl_global_sslget [2].
[1]: https://curl.haxx.se/libcurl/c/curl_global_sslset.html
[2]: https://github.com/curl/curl/pull/2063
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: 7.58.0 curl_global_sslset returns CURLSSLSET_TOO_LATE
On Tue, Jan 28, 2020 at 10:24 PM Ray Satiro via curl-library <
curl-library@cool.haxx.se> wrote:
> On 1/28/2020 1:17 PM, Pawel Veselov via curl-library wrote:
> >
> > I have a simple prologue code in my program to select SSL backend. It
> > works on relatively
> > recent versions (e.g. 7.65), but specifically on 7.58 ("latest" for
> > Ubuntu 18),
> > curl_global_sslset() returns CURLSSLSET_TOO_LATE.
> > I thought somebody else may be calling init function, but I can see
> > from the source code
> > that it simply returns TOO_LATE if there are no multiple SSL backends,
> > and if ID
> > doesn't match the ID of the backend that was actually compiled in.
> >
> > Could you please save me some investigative time and let me know in
> > which version
> > was this changed so that calling this with without IDs returns list of
> > available backends even
> > in case of single backend?
>
>
> sslset also returns too late if it has been called after global init.
>
global init hasn't been called.
> How are you calling it, with name or id?
I just want the list, so I pass id of -1 and name of 0.
> There was an issue when id was
> set to -1 that was fixed [1] a year ago. Also there was an improvement
> in 7.60 to return the backends even if too late [2]. The change is
> documented you could test for it like this:
>
>if(rc != CURLSSLSET_OK) {
> curl_version_info_data *verinfo = curl_version_info(CURLVERSION_NOW);
> if(verinfo->version_num >= CURL_VERSION_BITS(7,60,0)) {
>/* backend list available even if CURLSSLSET_TOO_LATE */
> }
>}
>
Ah, I see. The bone that I have to pick with this is that return of
TOO_LATE can happen because either global init was called, or
because there is only one backend (and I didn't guess right), and
I can't really tell the difference.
The whole deal here is that I want to prevent getting libcurl with one
backend in particular. I guess my logic should be:
* call sslset with -1/NULL. If that gives me a list of backends,
pick the one that I want, and call sslset again, and see if it worked
* If there was no list of backends, try to call with the bad
backend ID, and see if then it succeeds. If it does, then I have
a backend I don't want
>
> [1]: https://github.com/curl/curl/commit/2456152
> [2]: https://github.com/curl/curl/commit/d0394de
>
>
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: curl doesn't handle multiple WWW-Authenticate challenges properly (Negotiate)
On Tue, 28 Jan 2020, Mischa Salle wrote: In short, it's primarily a documentation issue with the manpage of curl itself, no longer a code issue. Thanks, I created a PR to fix it: https://github.com/curl/curl/pull/4862 -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: 7.58.0 curl_global_sslset returns CURLSSLSET_TOO_LATE
On 1/28/2020 1:17 PM, Pawel Veselov via curl-library wrote:
I have a simple prologue code in my program to select SSL backend. It
works on relatively
recent versions (e.g. 7.65), but specifically on 7.58 ("latest" for
Ubuntu 18),
curl_global_sslset() returns CURLSSLSET_TOO_LATE.
I thought somebody else may be calling init function, but I can see
from the source code
that it simply returns TOO_LATE if there are no multiple SSL backends,
and if ID
doesn't match the ID of the backend that was actually compiled in.
Could you please save me some investigative time and let me know in
which version
was this changed so that calling this with without IDs returns list of
available backends even
in case of single backend?
sslset also returns too late if it has been called after global init.
How are you calling it, with name or id? There was an issue when id was
set to -1 that was fixed [1] a year ago. Also there was an improvement
in 7.60 to return the backends even if too late [2]. The change is
documented you could test for it like this:
if(rc != CURLSSLSET_OK) {
curl_version_info_data *verinfo = curl_version_info(CURLVERSION_NOW);
if(verinfo->version_num >= CURL_VERSION_BITS(7,60,0)) {
/* backend list available even if CURLSSLSET_TOO_LATE */
}
}
[1]: https://github.com/curl/curl/commit/2456152
[2]: https://github.com/curl/curl/commit/d0394de
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Repeated calls to ares_init when using c-ares
When using c-ares for async DNS, every time curl_easy_init is called, libcurl calls ares_init via Curl_resolver_init. In an environment with many requests being done using the "multi" interface, this is slow. ares_init does things like read /etc/resolv.conf and initializing big arrays. It's enough that ares_init is showing up in CPU usage profiles. Is there a way for libcurl to use one instance of c-ares, rather than trying to create one for every curl_easy_init? --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
using Curl with android studio
Hi all,
I have developed software with C that works properly in windows. I used Curl
for internet communications. Recently I moved my all codes to Android Studio
and all things are good and I don't have any problem.
I have tried to use Curl in my application but even after following the rules
in the official site for using Curl in android, I didn't a success.
recommended things after some necceary changes : 1- export
NDK=~/mnt/C/Users/Asus/AppData/Local/Android/Sdk/ndk/20.1.59489442- export
HOST_TAG=windows-x86_643- export
TOOLCHAIN=$NDK/toolchains/llvm/prebuilt/$HOST_TAG4- export
AR=$TOOLCHAIN/bin/x86_64-linux-android-ar5- export
AS=$TOOLCHAIN/bin/x86_64-linux-android-as6- export
CC=$TOOLCHAIN/bin/x86_64-linux-android21-clang7- export
CXX=$TOOLCHAIN/bin/x86_64-linux-android21-clang++8- export
LD=$TOOLCHAIN/bin/x86_64-linux-android-ld9- export
RANLIB=$TOOLCHAIN/bin/x86_64-linux-android-ranlib10- export
STRIP=$TOOLCHAIN/bin/x86_64-linux-android-strip11- ./configure
--host=x86_64-linux-android --with-pic --disable-shared
---config.log :.../bin/arch =
x86_64/usr/bin/arch -k = unknown/usr/convex/getsysinfo =
unknown/usr/bin/hostinfo = unknown/bin/machine =
unknown/usr/bin/oslevel = unknown/bin/universe =
unknown...configure:3952: result:
/home/simorgh/mnt/C/Users/Asus/AppData/Local/Android/Sdk/ndk/20.1.5948944/toolchains/llvm/prebuilt/windows-x86_64/bin/x86_64-linux-android21-clangconfigure:4221:
checking for C compiler versionconfigure:4230:
/home/simorgh/mnt/C/Users/Asus/AppData/Local/Android/Sdk/ndk/20.1.5948944/toolchains/llvm/prebuilt/windows-x86_64/bin/x86_64-linux-android21-clang
--version >&5./configure: line 4232:
/home/simorgh/mnt/C/Users/Asus/AppData/Local/Android/Sdk/ndk/20.1.5948944/toolchains/llvm/prebuilt/windows-x86_64/bin/x86_64-linux-android21-clang:
No such file or directoryconfigure:4241: $? = 127
configure:4260: checking whether the C compiler worksconfigure:4282:
/home/simorgh/mnt/C/Users/Asus/AppData/Local/Android/Sdk/ndk/20.1.5948944/toolchains/llvm/prebuilt/windows-x86_64/bin/x86_64-linux-android21-clang
conftest.c >&5./configure: line 4284:
/home/simorgh/mnt/C/Users/Asus/AppData/Local/Android/Sdk/ndk/20.1.5948944/toolchains/llvm/prebuilt/windows-x86_64/bin/x86_64-linux-android21-clang:
No such file or directoryconfigure:4286: $? = 127configure:4324: result:
noconfigure: failed program was:| /* confdefs.h */| #define PACKAGE_NAME
"curl"| #define PACKAGE_TARNAME "curl"| #define PACKAGE_VERSION "-"| #define
PACKAGE_STRING "curl -"| #define PACKAGE_BUGREPORT "a suitable curl mailing
list: http://curl.haxx.se/mail/;| #define PACKAGE_URL ""| /* end confdefs.h.
*/| | int main (void)| {| | ;| return 0;| }configure:4329: error: in
`/mnt/e/AndroidStudioProjects/curla':configure:4331: error: C compiler cannot
create executables
configure: exit 77
Is there any way to use Curl in my Android project?
Thank you for taking the time,Khalil Torabi
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: curl doesn't handle multiple WWW-Authenticate challenges properly (Negotiate)
Hi Daniel, On Tue, Jan 28, 2020 at 5:40 PM Daniel Stenberg wrote: > On Tue, 28 Jan 2020, Mischa Salle wrote: > > Just for information, I ran into the same problem when trying to add both > > Basic and Bearer Authorization headers for an OAuth2 request. > > The same issue, really? You seem to be talking about *sending* two > www-authorization headers while Michel mentioned *receiving* more than one > authentication method in a single header. Oops, I was too quick (doing too many things at the same time), you're totally right of course... > > I actually there also had the problem that --oauth2-bearer actually > > doesn't work for https. > > This then sounds like a third issue. How doesn't it work? This sounds like an > issue nobody has told us about. Actually, I thought it was documented behaviour (although frustrating) to only support mail protocols, not http(s), which is why I never reported it: https://github.com/curl/curl/blob/master/docs/cmdline-opts/oauth2-bearer.d#L4 conform also the manpage of curl. But now I found https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_XOAUTH2_BEARER.3#L32 which pointed me to https://github.com/curl/curl/pull/2102, i.e. since 7.61 this should have been fixed and indeed I've just confirmed that a master (7.69-dev) indeed sets the Authorization: Bearer header, although it indeed doesn't work in combination with a --user. (it does say "* Server auth using Bearer with user 'client'" but does not actually do anything with the user). My OpenSUSE still comes with a 7.60, hence I hadn't seen it working. In short, it's primarily a documentation issue with the manpage of curl itself, no longer a code issue. > > Specifying both a --user client_id:client_secret and a -H "Authorization: > > Bearer myfirstbearertoken" only sends the latter it seems. > > curl will only send one Authorization: header, that is true. I've never seen > or been told a use case before where someone needed more than one. I agree it's a bit of an edge case, since most OAuth2 authorization servers will prefer - or at least allow - you to use POST parameters instead of authorization headers, but I've seen servers where it was needed (and there are several flows where the client needs to send both its client_id and secret *and* a token to the server, but most allow either of them via e.g. POST parameters instead). Best wishes, Mischa --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
7.58.0 curl_global_sslset returns CURLSSLSET_TOO_LATE
Hello.
I have a simple prologue code in my program to select SSL backend. It works
on relatively
recent versions (e.g. 7.65), but specifically on 7.58 ("latest" for Ubuntu
18),
curl_global_sslset() returns CURLSSLSET_TOO_LATE.
I thought somebody else may be calling init function, but I can see from
the source code
that it simply returns TOO_LATE if there are no multiple SSL backends, and
if ID
doesn't match the ID of the backend that was actually compiled in.
Could you please save me some investigative time and let me know in which
version
was this changed so that calling this with without IDs returns list of
available backends even
in case of single backend?
Thank you! :)
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: AW: [EXTERN] Re: curl doesn't handle multiple WWW-Authenticate challenges properly (Negotiate)
On Tue, 28 Jan 2020, Jung Michel wrote: If C was my language, I would :-) But I guess I'll bother IBM to change this. Oh boy... maybe I rather learn C :-P Just to be overly obvious, but you know, there's also always the solution mentioned in my signature... -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: curl doesn't handle multiple WWW-Authenticate challenges properly (Negotiate)
On Tue, 28 Jan 2020, Mischa Salle wrote: Just for information, I ran into the same problem when trying to add both Basic and Bearer Authorization headers for an OAuth2 request. The same issue, really? You seem to be talking about *sending* two www-authorization headers while Michel mentioned *receiving* more than one authentication method in a single header. I actually there also had the problem that --oauth2-bearer actually doesn't work for https. This then sounds like a third issue. How doesn't it work? This sounds like an issue nobody has told us about. Specifying both a --user client_id:client_secret and a -H "Authorization: Bearer myfirstbearertoken" only sends the latter it seems. curl will only send one Authorization: header, that is true. I've never seen or been told a use case before where someone needed more than one. -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: curl doesn't handle multiple WWW-Authenticate challenges properly (Negotiate)
On Tue, Jan 28, 2020 at 4:23 PM Daniel Stenberg via curl-library wrote: > > On Tue, 28 Jan 2020, Jung Michel via curl-library wrote: > > > However, if the 401 response contains more than one challenge, like so: > > > >WWW-Authenticate: Negotiate, Basic realm="TM1" > > This is accurate. curl doesn't handle multiple authentications specified on > the same physical line, but will deal with them if they arrive in multiple > headers. This limitation actually affects all HTTP authentication methods, not > just Negotiate. > > Amazingly enough, this is something that is extremely rare in practise in the > wild and therefore has not been much of a problem. Just for information, I ran into the same problem when trying to add both Basic and Bearer Authorization headers for an OAuth2 request. I actually there also had the problem that --oauth2-bearer actually doesn't work for https. Specifying both a --user client_id:client_secret and a -H "Authorization: Bearer myfirstbearertoken" only sends the latter it seems. Usually you can easily work around these things by manually setting all the headers using the -H flag but it's a bit frustrating. Best, Mischa > > You interested in diving in and work on fixing this? > > -- > > / daniel.haxx.se | Commercial curl support up to 24x7 is available! >| Private help, bug fixes, support, ports, new features >| https://www.wolfssl.com/contact/ > --- > Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library > Etiquette: https://curl.haxx.se/mail/etiquette.html --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
AW: [EXTERN] Re: curl doesn't handle multiple WWW-Authenticate challenges properly (Negotiate)
Thanks for the quick response > You interested in diving in and work on fixing this? If C was my language, I would :-) But I guess I'll bother IBM to change this. Oh boy... maybe I rather learn C :-P Disclaimer: Diese E-Mail enthält möglicherweise vertrauliche Informationen und ist einzig für den beabsichtigten Empfänger bestimmt. Sollten Sie diese E-Mail irrtümlicherweise erhalten haben, bitten wir Sie, die Zürcher Kantonalbank unverzüglich zu benachrichtigen und diese E-Mail sowie deren Anhänge sofort zu löschen. Unbefugte Verwendung kann geahndet werden. Vielen Dank. --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: curl doesn't handle multiple WWW-Authenticate challenges properly (Negotiate)
On Tue, 28 Jan 2020, Jung Michel via curl-library wrote: However, if the 401 response contains more than one challenge, like so: WWW-Authenticate: Negotiate, Basic realm="TM1" This is accurate. curl doesn't handle multiple authentications specified on the same physical line, but will deal with them if they arrive in multiple headers. This limitation actually affects all HTTP authentication methods, not just Negotiate. Amazingly enough, this is something that is extremely rare in practise in the wild and therefore has not been much of a problem. You interested in diving in and work on fixing this? -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
curl doesn't handle multiple WWW-Authenticate challenges properly (Negotiate)
Hi all, The following has been tested with versions - 7.29.0 (x86_64-redhat-linux-gnu) - 7.61.1 (x86_64-redhat-linux-gnu) - 7.64.0 (x86_64-w64-mingw32) I'm trying to use curl with Negotiate like so: curl -kv -L --negotiate -u : -b ~/cookie.txt -c ~/cookie.txt http://localhost:8081/negotiate If the first 401 response contains WWW-Authenticate: Negotiate curl will then, as expected, send another request with an Authorization header: Authorization: Negotiate x However, if the 401 response contains more than one challenge, like so: WWW-Authenticate: Negotiate, Basic realm="TM1" curl will NOT send another request. According to RFC2616 [1], sending multiple challenges like this is valid. Is there a way to handle this case, or is this a bug in libcurl? Ultimately, I'm trying to do such requests using R which uses libcurl under the hood. Thank you for taking the time, Michel Jung [1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.47 Disclaimer: Diese E-Mail enthält möglicherweise vertrauliche Informationen und ist einzig für den beabsichtigten Empfänger bestimmt. Sollten Sie diese E-Mail irrtümlicherweise erhalten haben, bitten wir Sie, die Zürcher Kantonalbank unverzüglich zu benachrichtigen und diese E-Mail sowie deren Anhänge sofort zu löschen. Unbefugte Verwendung kann geahndet werden. Vielen Dank. --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Test 323 fails, even on Intel processor
On 1/28/20 7:56 AM, Daniel Stenberg wrote: Did you build with any other special options, like sanitizers etc? export CPPFLAGS="-DCURL_DOES_CONVERSIONS -DHAVE_ICONV -DCURL_ICONV_CODESET_OF_HOST='\"ISO8859-1\"'" export CFLAGS="-g -O3" ./configure --prefix=/usr --with-ssl --without-gnutls --enable-debug I also tried with -O0 and it still fails. --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
