Buy commercial curl support from WolfSSL. 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
himself.
Re: CURLINFO_REDIRECT_COUNT
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Mellergård, Daniel via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 7 Dec 2022 14:01:22 +0000
> What are you proposing we should do?
I acknowledge that the CURLOPT_HTTPAUTH is set per transfer. So if I set CURLAUTH_DIGEST, curl should really try Digest and in the same manner I understand that CURLAUTH_ANY* is also set "per transfer". Strictly interpreted this should require curl to renegotiate for every single transfer that is requested.
But at the same time CURLAUTH_ANY* is a bit loosely defined ("libcurl will automatically select the one it finds most secure"). I don't know if there are RFC:s that require a new negotiation with the host for each new request? Otherwise, I think curl should be a bit free to use whatever auth method works best for the moment. That is, the user has not set any fixed requirements and we already have an existing authentication with the host, that at least earlier was the most secure and best matched.
So for example, for Digest an extra roundtrip to get the nonce-value for the next message will be needed. But for Basic, it should only be a matter of continuing to add the basic auth headers when we have an existing basic-auth authentication with the host. (Assuming the user has not changed credentials between requests.) If a 401 is received (unlikely), a new "negotiation" can be made, potentially resulting in something else than Basic and the message can be resent.
I guess this optimization will mostly be for Basic, maybe it could be used for some other auth methods. You probably know that best. But even if it's only implemented for Basic, that has to be the most common auth method used, so it will be valuable anyway.
Date: Wed, 7 Dec 2022 14:01:22 +0000
> What are you proposing we should do?
I acknowledge that the CURLOPT_HTTPAUTH is set per transfer. So if I set CURLAUTH_DIGEST, curl should really try Digest and in the same manner I understand that CURLAUTH_ANY* is also set "per transfer". Strictly interpreted this should require curl to renegotiate for every single transfer that is requested.
But at the same time CURLAUTH_ANY* is a bit loosely defined ("libcurl will automatically select the one it finds most secure"). I don't know if there are RFC:s that require a new negotiation with the host for each new request? Otherwise, I think curl should be a bit free to use whatever auth method works best for the moment. That is, the user has not set any fixed requirements and we already have an existing authentication with the host, that at least earlier was the most secure and best matched.
So for example, for Digest an extra roundtrip to get the nonce-value for the next message will be needed. But for Basic, it should only be a matter of continuing to add the basic auth headers when we have an existing basic-auth authentication with the host. (Assuming the user has not changed credentials between requests.) If a 401 is received (unlikely), a new "negotiation" can be made, potentially resulting in something else than Basic and the message can be resent.
I guess this optimization will mostly be for Basic, maybe it could be used for some other auth methods. You probably know that best. But even if it's only implemented for Basic, that has to be the most common auth method used, so it will be valuable anyway.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-12-07