libcurl CURLINFO_PROXYAUTH_USED:获取 HTTP 代理实际使用的认证方式

发布时间:2026/9/10 6:18:09
libcurl CURLINFO_PROXYAUTH_USED:获取 HTTP 代理实际使用的认证方式
libcurl CURLINFO_PROXYAUTH_USED获取 HTTP 代理实际使用的认证方式【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl本文基于 libcurl 官方手册CURLINFO_PROXYAUTH_USED(3)与当前仓库源码讲解该curl_easy_getinfo查询项的接口契约、返回值位图语义与完整使用示例并追踪其内部写入路径407 处理与认证头输出帮助你在经过 HTTP 代理的传输完成后准确判定代理侧究竟采用了哪种认证方式以及为何返回值为 0。1. 接口定义与版本前提CURLINFO_PROXYAUTH_USED是一个CURLINFO_LONG类型的查询项用于读取“上一次经过 HTTP 代理的请求所实际使用的认证方法”。其声明位于公共头文件 include/curl/curl.h 的CURLINFO枚举中/* include/curl/curl.h */ CURLINFO_HTTPAUTH_USED CURLINFO_LONG 69, CURLINFO_PROXYAUTH_USED CURLINFO_LONG 70,调用形式与手册 SYNOPSIS 一致#include curl/curl.h CURLcode curl_easy_getinfo(CURL *handle, CURLINFO_PROXYAUTH_USED, long *authp);关键约束版本前提该查询项自8.12.0起可用见文档头Added-in: 8.12.0。在更早版本上调用它会得到CURLE_UNKNOWN_OPTION类的未知信息项错误。协议范围仅适用于 HTTP经过 HTTP 代理场景这一点由文档 front-matter 中Protocol: HTTP标明。参数类型必须传入一个long的指针。若传入类型不匹配的指针curl_easy_getinfo会返回CURLE_BAD_FUNCTION_ARGUMENT。2. 返回值语义一个“至多一位”的位图手册明确说明传入long指针接收一个位图该位图的含义与CURLOPT_HTTPAUTH(3)选项的位定义相同并且“返回值只有零位或一位被置位”zero or one bit set。也就是说返回值不是“允许的认证方式集合”而是最终实际使用的那一种或不使用。可取位的定义见 include/curl/curl.h#define CURLAUTH_NONE ((unsigned long)0) #define CURLAUTH_BASIC (((unsigned long)1) 0) #define CURLAUTH_DIGEST (((unsigned long)1) 1) #define CURLAUTH_NEGOTIATE (((unsigned long)1) 2) #define CURLAUTH_NTLM (((unsigned long)1) 3) #define CURLAUTH_DIGEST_IE (((unsigned long)1) 4) #define CURLAUTH_BEARER (((unsigned long)1) 6) #define CURLAUTH_AWS_SIGV4 (((unsigned long)1) 7) #define CURLAUTH_HTTPSIG (((unsigned long)1) 8)据此可归纳返回值对照返回值含义0CURLAUTH_NONE本次经代理的请求没有使用任何认证代理未要求 407 挑战或未提供代理凭据CURLAUTH_BASIC(1)代理采用 Basic 认证CURLAUTH_DIGEST(2)代理采用 Digest 认证CURLAUTH_NEGOTIATE(4)代理采用 Negotiate/SPNEGO 认证CURLAUTH_NTLM(8)代理采用 NTLM 认证CURLAUTH_BEARER(64)代理采用 Bearer token 认证由于“至多一位”的契约实践中用比较比位运算更直观官方示例也正是这么写的。3. 完整使用示例官方示例原样保留下面的示例来自 docs/libcurl/opts/CURLINFO_PROXYAUTH_USED.md展示了完整链路设置代理 → 配置允许的代理认证方式Basic | Digest与代理账号 → 执行传输 → 查询实际使用的认证方式int main(void) { CURL *curl curl_easy_init(); if(curl) { CURLcode result; curl_easy_setopt(curl, CURLOPT_URL, https://example.com); curl_easy_setopt(curl, CURLOPT_PROXY, http://proxy.example); curl_easy_setopt(curl, CURLOPT_PROXYAUTH, CURLAUTH_BASIC | CURLAUTH_DIGEST); curl_easy_setopt(curl, CURLOPT_PROXYUSERNAME, shrek); curl_easy_setopt(curl, CURLOPT_PROXYPASSWORD, swamp); result curl_easy_perform(curl); if(result CURLE_OK) { long auth; result curl_easy_getinfo(curl, CURLINFO_PROXYAUTH_USED, auth); if(result CURLE_OK) { if(!auth) printf(No auth used\n); else { if(auth CURLAUTH_DIGEST) printf(Used Digest proxy authentication\n); else printf(Used Basic proxy authentication\n); } } } curl_easy_cleanup(curl); } }返回值的错误语义curl_easy_getinfo返回CURLcodeCURLE_OK (0)表示成功非零表示出错例如查询时机不对或传入了错误类型的指针错误码含义参见libcurl-errors(3)。4. 源码级原理proxyauthpicked何时被写入查询项最终读取的是一个内部字段。在 lib/urldata.h 中可以看到该字段的定义与注释/* lib/urldata.h */ uint32_t proxyauthpicked; /* selected proxy auth type */4.1 读取路径在curl_easy_getinfo的实现 lib/getinfo.c 中CURLINFO_PROXYAUTH_USED分支直接将上述字段转写到调用者的long输出case CURLINFO_PROXYAUTH_USED: lptr.to_long param_longp; *lptr.to_ulong >#ifndef CURL_DISABLE_PROXY if(conn-http_proxy.creds ((data-req.httpcode 407) || (data-req.authneg >if(auth) { #ifndef CURL_DISABLE_PROXY if(proxy) >data-info.proxyauthpicked CURLAUTH_NTLM;该处逻辑对主机与代理共用同一authstatus上下文从源码结构看NTLM 会话成功收尾时proxyauthpicked会被置为CURLAUTH_NTLM。5. 与相关接口的协作关系理解CURLINFO_PROXYAUTH_USED时值得把它放进“允许 / 可用 / 实际使用”三层来看接口角色说明CURLOPT_PROXYAUTH允许通过curl_easy_setopt设置允许使用的代理认证方式位图。在 lib/setopt.c 中由setopt_long_proxy分发给内部函数httpauth(data, TRUE, arg)TRUE表示这是代理侧的认证配置CURLINFO_PROXYAUTH_AVAIL可用读取代理在WWW-Authenticate/Proxy-Authenticate挑战中声明的可用方式集合对应 lib/getinfo.c 中的data-info.proxyauthavailCURLINFO_PROXYAUTH_USED实际使用读取data-info.proxyauthpicked即最终真正采用的单一方式典型调试套路当请求经代理失败或行为异常时先查CURLINFO_PROXYAUTH_AVAIL确认代理声明了哪些方式再查CURLINFO_PROXYAUTH_USED确认 libcurl 实际挑了哪种最后核对CURLOPT_PROXYAUTH的允许集合是否与之匹配——例如代理只支持 Negotiate而你的PROXYAUTH只给了CURLAUTH_BASIC挑选就会失败并置authproblem见 lib/http.c 的pickoneauth失败分支。6. 使用注意查询时机必须在对应传输的curl_easy_perform完成之后调用curl_easy_getinfo它反映的是“the previous request”上一次请求的结果。仅 HTTP 代理若传输未经过 HTTP 代理未设CURLOPT_PROXY或走 SOCKS 等该值通常为0不能据此推断失败原因。只读语义这是一个只读查询项不要试图用curl_easy_setopt设置它设置CURLINFO值会返回CURLE_UNKNOWN_OPTION。与CURLAUTH_ANY的关系即使CURLOPT_PROXYAUTH传入了CURLAUTH_ANY返回的USED值仍然是单一位图不会返回ANY这个多区位掩码。版本兼容依赖该查询项的部署目标需保证 libcurl ≥ 8.12.0对旧版本应做特性检测或使用curl_version_info判断而不是假设符号存在。7. 仓库内延伸阅读查询项定义include/curl/curl.hCURLINFO_HTTPAUTH_USED/CURLINFO_PROXYAUTH_USED枚举值读取实现lib/getinfo.c内部状态字段lib/urldata.h407 挑战与认证挑选lib/http.c认证头输出与清零lib/http.cNTLM 收尾赋值lib/http_ntlm.cCURLOPT_PROXYAUTH的 setopt 处理lib/setopt.c官方手册原文docs/libcurl/opts/CURLINFO_PROXYAUTH_USED.md姊妹篇服务器侧认证docs/libcurl/opts/CURLINFO_HTTPAUTH_USED.md【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考