尧图网页设计 
libcurl CURLINFO_RESPONSE_CODE获取传输完成后的最后响应码HTTP/FTP/SMTP/LDAP【免费下载链接】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/curlCURLINFO_RESPONSE_CODE是 libcurl 中通过curl_easy_getinfo()读取传输结果的关键信息项之一传输结束后用它可以取回服务器返回的最后一个响应码涵盖 HTTP 状态码、FTP 应答码、SMTP 应答码与 LDAP仅 OpenLDAP结果码。本文以 CURLINFO_RESPONSE_CODE 官方手册页 为主体结合本仓库的公开头文件与核心源码完整讲清该选项的定义、语义、版本演进、跨协议的取值来源以及与代理 CONNECT 应答码选项的边界帮助你在集成 libcurl 的程序中正确、可靠地解析服务器响应。一、选项定义与调用方式官方手册给出的标准调用签名如下#include curl/curl.h CURLcode curl_easy_getinfo(CURL *handle, CURLINFO_RESPONSE_CODE, long *codep);从当前仓库的公开头文件可以确认其枚举定义/* include/curl/curl.h */ CURLINFO_EFFECTIVE_URL CURLINFO_STRING 1, CURLINFO_RESPONSE_CODE CURLINFO_LONG 2,两个值得注意的细节见 include/curl/curl.h该枚举值是CURLINFO_LONG 2即它属于long 类型的 getinfo 项因此必须传入一个long *指针它是CURLINFO枚举中的第 2 个信息项仅次于CURLINFO_EFFECTIVE_URL属于 libcurl 最早期、最核心的结果查询接口之一。调用时序上该选项应当在curl_easy_perform()完成无论返回CURLE_OK还是错误码之后再查询因为响应码只在传输过程中由服务器应答填充。二、返回值的语义按协议区分含义官方手册CURLINFO_RESPONSE_CODE.md的 DESCRIPTION 部分说明传入一个long指针即可收到最后收到的HTTP、FTP、SMTP 或 LDAP仅 OpenLDAP 后端响应码。若尚未收到任何服务器响应码存储的值为0。结合仓库源码可以按协议列出该值的具体含义与各协议在实现中的写入点协议返回值含义源码写入位置HTTP最后一条状态行的 HTTP 状态码如 200、301、404、416lib/http.cFTP最后一次 FTP 应答码lib/ftp.cSMTP最后一次 SMTP 应答码lib/smtp.cLDAP最后一条 LDAP 操作结果码仅 OpenLDAP 后端lib/openldap.c、lib/openldap.c从源码结构看四种协议写入的是同一个存储字段data-info.httpcode。例如/* lib/smtp.c */>int main(void) { CURL *curl curl_easy_init(); if(curl) { CURLcode result; curl_easy_setopt(curl, CURLOPT_URL, https://example.com); result curl_easy_perform(curl); if(result CURLE_OK) { long response_code; curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, response_code); } curl_easy_cleanup(curl); } }实际集成时建议做三点强化检查 getinfo 自身的返回码。curl_easy_getinfo()返回CURLcodeCURLE_OK (0)表示成功非零表示出错详见libcurl-errors(3)手册页。类型不匹配例如传入int *却声明为 LONG 类型项会返回CURLE_BAD_FUNCTION_ARGUMENT。区分 0 与有效码。手册明确未收到响应码时存值为 0所以response_code 0不能按 200 处理通常意味着传输在收到应答前就失败如连接错误、TLS 失败。结合CURLOPT_FAILONERROR使用。若设置了CURLOPT_FAILONERRORHTTP 4xx/5xx 会使curl_easy_perform()返回CURLE_HTTP_RETURNED_ERROR此时CURLINFO_RESPONSE_CODE仍然保留了具体状态码可用于区分 401 与 404 等细粒度逻辑。四、名称演进与版本历史手册 NOTES 与 front matter 记录了完整的版本脉络事件版本原名CURLINFO_HTTP_CODE引入7.4.1更名为CURLINFO_RESPONSE_CODE当前名7.10.8支持 SMTP 响应码7.25.0支持 OpenLDAP 结果码7.81.0头文件中保留了向后兼容的宏别名这也是老代码无需修改即可编译的原因include/curl/curl.h/* CURLINFO_RESPONSE_CODE is the new name for the option previously known as CURLINFO_HTTP_CODE */ #define CURLINFO_HTTP_CODE CURLINFO_RESPONSE_CODEfront matter 中还声明了该选项适用的协议集合HTTP、FTP、SMTP、LDAP与正文描述一致。五、源码视角响应码如何被解析与存储理解底层写入链路有助于解释一些边界行为如0 值何时出现。1. 查询入口。curl_easy_getinfo()的 long 类型分发在 lib/getinfo.cswitch(info) { case CURLINFO_RESPONSE_CODE: *param_longp >k-httpcode ((p[0] - 0) * 100) ((p[1] - 0) * 10) ...源码中还包含若干协议细节处理例如按 HTTP/0.9 语义在无状态行时按 200 处理lib/http.c、304 Not Modified 的专门赋值lib/http.c以及 416Range Not Satisfiable、417Expectation Failed在请求流中的特殊分支lib/http.c、lib/http.c。3. 与代理的交互。当经过 HTTP 代理时lib/cf-h1-proxy.c 会先把data-info.httpcode清零注释说明它可能被上一段使用过随后代理对 CONNECT 的应答会被同时写入httpproxycode与httpcode见 lib/cf-h1-proxy.c、lib/cf-h1-proxy.c。这解释了为什么官方特别强调代理的 CONNECT 应答应读取CURLINFO_HTTP_CONNECTCODE而不是本选项。六、与 CURLINFO_HTTP_CONNECTCODE 的对比两个选项经常混淆差异对照如下对比项CURLINFO_RESPONSE_CODECURLINFO_HTTP_CONNECTCODE读取字段data-info.httpcodedata-info.httpproxycode语义最后收到的服务器响应码HTTP/FTP/SMTP/LDAP代理对 CONNECT 请求的响应码适用协议HTTP、FTP、SMTP、LDAP仅 HTTP经代理典型值200、304、404、416200隧道建立成功未收到时00引入版本7.10.8原名 7.4.17.10.7CURLINFO_HTTP_CONNECTCODE的完整说明见 CURLINFO_HTTP_CONNECTCODE.md。在HTTPS over 代理场景中一个健壮的客户端应同时检查两者CONNECT 码确认隧道握手成功CURLINFO_RESPONSE_CODE再确认目标站点的最终状态。七、实践要点小结该选项是long类型信息项查询参数必须为long *且建议在curl_easy_perform()之后调用返回 0 表示没有收到响应码不应与 200 混淆启用CURLOPT_FOLLOWLOCATION跟随重定向时最后收到的响应码即为重定向链最终一跳的状态码中间跳的 3xx 不会保留需要区分目标站点响应与代理 CONNECT 响应时分别使用CURLINFO_RESPONSE_CODE与CURLINFO_HTTP_CONNECTCODE两者的取值字段与语义在源码层面是相互独立的见 lib/getinfo.c老代码中的CURLINFO_HTTP_CODE与当前选项等价由 include/curl/curl.h 中的宏别名保证兼容新代码应优先使用CURLINFO_RESPONSE_CODE。八、返回值curl_easy_getinfo()返回一个CURLcode指示成功或失败CURLE_OK (0)表示一切正常非零表示发生错误参见libcurl-errors(3)。【免费下载链接】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），仅供参考 libcurl CURLINFO_RESPONSE_CODE：获取传输完成后的最后响应码（HTTP/FTP/SMTP/LDAP）
libcurl CURLINFO_RESPONSE_CODE获取传输完成后的最后响应码HTTP/FTP/SMTP/LDAP【免费下载链接】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/curlCURLINFO_RESPONSE_CODE是 libcurl 中通过curl_easy_getinfo()读取传输结果的关键信息项之一传输结束后用它可以取回服务器返回的最后一个响应码涵盖 HTTP 状态码、FTP 应答码、SMTP 应答码与 LDAP仅 OpenLDAP结果码。本文以 CURLINFO_RESPONSE_CODE 官方手册页 为主体结合本仓库的公开头文件与核心源码完整讲清该选项的定义、语义、版本演进、跨协议的取值来源以及与代理 CONNECT 应答码选项的边界帮助你在集成 libcurl 的程序中正确、可靠地解析服务器响应。一、选项定义与调用方式官方手册给出的标准调用签名如下#include curl/curl.h CURLcode curl_easy_getinfo(CURL *handle, CURLINFO_RESPONSE_CODE, long *codep);从当前仓库的公开头文件可以确认其枚举定义/* include/curl/curl.h */ CURLINFO_EFFECTIVE_URL CURLINFO_STRING 1, CURLINFO_RESPONSE_CODE CURLINFO_LONG 2,两个值得注意的细节见 include/curl/curl.h该枚举值是CURLINFO_LONG 2即它属于long 类型的 getinfo 项因此必须传入一个long *指针它是CURLINFO枚举中的第 2 个信息项仅次于CURLINFO_EFFECTIVE_URL属于 libcurl 最早期、最核心的结果查询接口之一。调用时序上该选项应当在curl_easy_perform()完成无论返回CURLE_OK还是错误码之后再查询因为响应码只在传输过程中由服务器应答填充。二、返回值的语义按协议区分含义官方手册CURLINFO_RESPONSE_CODE.md的 DESCRIPTION 部分说明传入一个long指针即可收到最后收到的HTTP、FTP、SMTP 或 LDAP仅 OpenLDAP 后端响应码。若尚未收到任何服务器响应码存储的值为0。结合仓库源码可以按协议列出该值的具体含义与各协议在实现中的写入点协议返回值含义源码写入位置HTTP最后一条状态行的 HTTP 状态码如 200、301、404、416lib/http.cFTP最后一次 FTP 应答码lib/ftp.cSMTP最后一次 SMTP 应答码lib/smtp.cLDAP最后一条 LDAP 操作结果码仅 OpenLDAP 后端lib/openldap.c、lib/openldap.c从源码结构看四种协议写入的是同一个存储字段data-info.httpcode。例如/* lib/smtp.c */>int main(void) { CURL *curl curl_easy_init(); if(curl) { CURLcode result; curl_easy_setopt(curl, CURLOPT_URL, https://example.com); result curl_easy_perform(curl); if(result CURLE_OK) { long response_code; curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, response_code); } curl_easy_cleanup(curl); } }实际集成时建议做三点强化检查 getinfo 自身的返回码。curl_easy_getinfo()返回CURLcodeCURLE_OK (0)表示成功非零表示出错详见libcurl-errors(3)手册页。类型不匹配例如传入int *却声明为 LONG 类型项会返回CURLE_BAD_FUNCTION_ARGUMENT。区分 0 与有效码。手册明确未收到响应码时存值为 0所以response_code 0不能按 200 处理通常意味着传输在收到应答前就失败如连接错误、TLS 失败。结合CURLOPT_FAILONERROR使用。若设置了CURLOPT_FAILONERRORHTTP 4xx/5xx 会使curl_easy_perform()返回CURLE_HTTP_RETURNED_ERROR此时CURLINFO_RESPONSE_CODE仍然保留了具体状态码可用于区分 401 与 404 等细粒度逻辑。四、名称演进与版本历史手册 NOTES 与 front matter 记录了完整的版本脉络事件版本原名CURLINFO_HTTP_CODE引入7.4.1更名为CURLINFO_RESPONSE_CODE当前名7.10.8支持 SMTP 响应码7.25.0支持 OpenLDAP 结果码7.81.0头文件中保留了向后兼容的宏别名这也是老代码无需修改即可编译的原因include/curl/curl.h/* CURLINFO_RESPONSE_CODE is the new name for the option previously known as CURLINFO_HTTP_CODE */ #define CURLINFO_HTTP_CODE CURLINFO_RESPONSE_CODEfront matter 中还声明了该选项适用的协议集合HTTP、FTP、SMTP、LDAP与正文描述一致。五、源码视角响应码如何被解析与存储理解底层写入链路有助于解释一些边界行为如0 值何时出现。1. 查询入口。curl_easy_getinfo()的 long 类型分发在 lib/getinfo.cswitch(info) { case CURLINFO_RESPONSE_CODE: *param_longp >k-httpcode ((p[0] - 0) * 100) ((p[1] - 0) * 10) ...源码中还包含若干协议细节处理例如按 HTTP/0.9 语义在无状态行时按 200 处理lib/http.c、304 Not Modified 的专门赋值lib/http.c以及 416Range Not Satisfiable、417Expectation Failed在请求流中的特殊分支lib/http.c、lib/http.c。3. 与代理的交互。当经过 HTTP 代理时lib/cf-h1-proxy.c 会先把data-info.httpcode清零注释说明它可能被上一段使用过随后代理对 CONNECT 的应答会被同时写入httpproxycode与httpcode见 lib/cf-h1-proxy.c、lib/cf-h1-proxy.c。这解释了为什么官方特别强调代理的 CONNECT 应答应读取CURLINFO_HTTP_CONNECTCODE而不是本选项。六、与 CURLINFO_HTTP_CONNECTCODE 的对比两个选项经常混淆差异对照如下对比项CURLINFO_RESPONSE_CODECURLINFO_HTTP_CONNECTCODE读取字段data-info.httpcodedata-info.httpproxycode语义最后收到的服务器响应码HTTP/FTP/SMTP/LDAP代理对 CONNECT 请求的响应码适用协议HTTP、FTP、SMTP、LDAP仅 HTTP经代理典型值200、304、404、416200隧道建立成功未收到时00引入版本7.10.8原名 7.4.17.10.7CURLINFO_HTTP_CONNECTCODE的完整说明见 CURLINFO_HTTP_CONNECTCODE.md。在HTTPS over 代理场景中一个健壮的客户端应同时检查两者CONNECT 码确认隧道握手成功CURLINFO_RESPONSE_CODE再确认目标站点的最终状态。七、实践要点小结该选项是long类型信息项查询参数必须为long *且建议在curl_easy_perform()之后调用返回 0 表示没有收到响应码不应与 200 混淆启用CURLOPT_FOLLOWLOCATION跟随重定向时最后收到的响应码即为重定向链最终一跳的状态码中间跳的 3xx 不会保留需要区分目标站点响应与代理 CONNECT 响应时分别使用CURLINFO_RESPONSE_CODE与CURLINFO_HTTP_CONNECTCODE两者的取值字段与语义在源码层面是相互独立的见 lib/getinfo.c老代码中的CURLINFO_HTTP_CODE与当前选项等价由 include/curl/curl.h 中的宏别名保证兼容新代码应优先使用CURLINFO_RESPONSE_CODE。八、返回值curl_easy_getinfo()返回一个CURLcode指示成功或失败CURLE_OK (0)表示一切正常非零表示发生错误参见libcurl-errors(3)。【免费下载链接】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），仅供参考