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 09:33:29 +0000
> The previous auth, as in *the existing* auth is reused as in the header is set when you have the same credentials and do another transfer.
> But the server might retrigger "negotiation" in several of the auths (Digest, Negotiate, NTLM etc) and then curl might get a 401/407 and then send an updated auth header.
>
> For NTLM, it is used to authenticate the connection so it is different.
>
> When you ask for auth to begin with and you allow more than one method, curl will need at least one roundtrip to first get to know which auth methods that the server accepts.
Excellent info!
I setup transfers to be using CURLOPT_HTTPAUTH=CURLAUTH_ANY (with https). If I instead specify CURLAUTH_BASIC to be used, I will not get any "redirects". (After negotiation I get Basic.)
So one workaround that I could probably implement, is to keep track of the most recently used http auth method for a specific origin, and set that explicitly for successive transfers. (There is no CURLINFO_EFFECTIVE_AUTH_METHOD, so I guess I would have to use CURLINFO_HTTPAUTH_AVAIL somehow instead.)
I *do* think, the user of the library shouldn't have to make such a workaround when using CURLAUTH_ANY*? For a few requests it doesn't probably matter, but for lots of requests (streaming), it will affect performance.
Date: Wed, 7 Dec 2022 09:33:29 +0000
> The previous auth, as in *the existing* auth is reused as in the header is set when you have the same credentials and do another transfer.
> But the server might retrigger "negotiation" in several of the auths (Digest, Negotiate, NTLM etc) and then curl might get a 401/407 and then send an updated auth header.
>
> For NTLM, it is used to authenticate the connection so it is different.
>
> When you ask for auth to begin with and you allow more than one method, curl will need at least one roundtrip to first get to know which auth methods that the server accepts.
Excellent info!
I setup transfers to be using CURLOPT_HTTPAUTH=CURLAUTH_ANY (with https). If I instead specify CURLAUTH_BASIC to be used, I will not get any "redirects". (After negotiation I get Basic.)
So one workaround that I could probably implement, is to keep track of the most recently used http auth method for a specific origin, and set that explicitly for successive transfers. (There is no CURLINFO_EFFECTIVE_AUTH_METHOD, so I guess I would have to use CURLINFO_HTTPAUTH_AVAIL somehow instead.)
I *do* think, the user of the library shouldn't have to make such a workaround when using CURLAUTH_ANY*? For a few requests it doesn't probably matter, but for lots of requests (streaming), it will affect performance.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-12-07