Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Feature Proposal: Support for additional environment variables for proxy authentication in libcurl
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Jörn Franke via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 9 Aug 2024 16:10:13 +0200
Thank you for the answer. It makes sense to me.
I guess it is a dilemma - on the one hand the libraries that use libcurl, but do not offer properly to configure it and thus people resorting to environment variables.
It is fine for me to not add yet another environment variable, but do you see it as useful to add to the documentation of the environment variables a warning that they should not be used to configure libcurl and that libraries/applications using libcurl should expose an interface themselves to configure relevant options of libcurl (especially proxies)?
> Am 09.08.2024 um 14:17 schrieb Daniel Stenberg <daniel_at_haxx.se>:
>
> On Thu, 8 Aug 2024, Jörn Franke via curl-library wrote:
>
>> Currently, libcurl provides environment variables to configure a proxy
>
> ...
>
>> It would be nice if curl could expose an environment variable [scheme]_proxyauth the option CURL_PROXYAUTH
>
> The general consensus is that environment variables is a quirky and unfriendly way to control functionality. A bad API. It also adds confusion when there are environment variables saying one thing and an API is used to say something else.
>
> The proxy environment variables libcurl supports were invented in the 90s and they were already in use by others at the time - which is why curl supports them. I am not at all convinced that inventing new proxy environment variables in 2024 that are curl specific is an awesome idea.
>
> If I could go back in time, I think maybe I would argue that curl should read the environment variables and pass them on to libcurl using the normal API. Bindings and libcurl users can do just that for any additional environment variables they think should be accepted.
>
> Finally: if a libcurl using application sets CURL_PROXYAUTH to a set of acceptable methods (more than one), libcurl will probe the server and use a method that the site accepts and that libcurl works with - ie not go with just Basic or similar. This does at least somewhat take away the need for a user to be specific about it.
>
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
Date: Fri, 9 Aug 2024 16:10:13 +0200
Thank you for the answer. It makes sense to me.
I guess it is a dilemma - on the one hand the libraries that use libcurl, but do not offer properly to configure it and thus people resorting to environment variables.
It is fine for me to not add yet another environment variable, but do you see it as useful to add to the documentation of the environment variables a warning that they should not be used to configure libcurl and that libraries/applications using libcurl should expose an interface themselves to configure relevant options of libcurl (especially proxies)?
> Am 09.08.2024 um 14:17 schrieb Daniel Stenberg <daniel_at_haxx.se>:
>
> On Thu, 8 Aug 2024, Jörn Franke via curl-library wrote:
>
>> Currently, libcurl provides environment variables to configure a proxy
>
> ...
>
>> It would be nice if curl could expose an environment variable [scheme]_proxyauth the option CURL_PROXYAUTH
>
> The general consensus is that environment variables is a quirky and unfriendly way to control functionality. A bad API. It also adds confusion when there are environment variables saying one thing and an API is used to say something else.
>
> The proxy environment variables libcurl supports were invented in the 90s and they were already in use by others at the time - which is why curl supports them. I am not at all convinced that inventing new proxy environment variables in 2024 that are curl specific is an awesome idea.
>
> If I could go back in time, I think maybe I would argue that curl should read the environment variables and pass them on to libcurl using the normal API. Bindings and libcurl users can do just that for any additional environment variables they think should be accepted.
>
> Finally: if a libcurl using application sets CURL_PROXYAUTH to a set of acceptable methods (more than one), libcurl will probe the server and use a method that the site accepts and that libcurl works with - ie not go with just Basic or similar. This does at least somewhat take away the need for a user to be specific about it.
>
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-08-09