TEN-framework 中 curl 组件的弃用特性清单解析：NSS/gskit/旧版 MinGW 与空格分隔 NO_PROXY 的移除计划

人工智能AI Agent多模态语音AI 应用【免费下载链接】ten-frameworkOpen-source framework for conversational voice AI agents项目地址https://gitcode.com/TEN-framework/ten-framework点击查看免费下载本指南基于本仓库third_party/curl/docs/DEPRECATE.md展开梳理 curl 计划从未来版本中移除的四个弃用特性NSS、gskit、mingw v1、空格分隔的NOPROXY模式并结合本仓库内 curl 源码configure.ac、lib/noproxy.c、单元测试等逐一验证这些弃用项在代码中的真实表现。读完本文你将掌握每个弃用项的背景、官方给出的替代方案、相应的 configure 过渡开关以及NO_PROXY列表分隔符的解析细节与迁移建议。一、总览这份清单是什么弃用清单 是 curl 官方仓库中一份面向维护者与下游集成方的移除预告。它列出 curl 计划从后续发布版本中删除的功能并提前数月至一年发出警告给仍然依赖这些功能的用户留出迁移窗口。文档开头明确呼吁如果其中任何一个弃用特性对你的使用场景造成困扰请尽快向 curl-library 邮件列表说明情况解释为什么你的用例无法通过替代方案满足——这是 curl 社区在移除特性前收集反馈的标准流程。本仓库将 curl 以第三方源码形式内嵌于third_party/curl/因此这份弃用清单同样适用于任何基于本仓库构建、且启用了相关后端的场景。清单共包含四类将被移除的项以及一份过往已移除项的回顾列表。二、NSSTLS 库后端的移除移除时间线与理由curl 计划在 2023 年 8 月移除对使用NSSNetwork Security ServicesTLS 库构建 curl 的支持。文档给出的理由包括使用 curlNSS 组合的用户已经很少NSS 在 curl 之外的使用者也寥寥无几主要是 Firefox 浏览器NSS 的文档比以往更难找到NSS 一直最适合配合 Red Hat Linux 使用因为 Red Hat 在普通 NSS 之上提供了额外的功能而这些功能并未包含在 vanilla原版库中。过渡期的 configure 开关从 curl 7.82.0 开始构建 curl 以使用 NSS 时configure 需要额外增加标志--with-nss-deprecated以此向构建者明确强调这些移除计划。本仓库的configure.ac中可以看到该机制的完整实现configure.ac#L297-L303 定义了--with-nss-deprecated参数帮助文本为 confirm you realize NSS is going away将值存入OPT_NSS_AWAREconfigure.ac#L305-L317 处理--with-nssPATH时若用户没有同时声明--with-nss-deprecated则会直接报错NSS use must be confirmed using --with-nss-deprecated. NSS support will be dropped from curl in August 2022. See docs/DEPRECATE.md注意configure.ac 中的报错文本写的是 August 2022而 DEPRECATE.md 正文给出的移除时间是 2023 年 8 月这是仓库内时间表述上的一处出入实际以 弃用清单 为准。在 CMake 构建路径中NSS 仍然是可选的 TLS 后端之一CURL_USE_NSS参见 CMakeLists.txt#L373 及特性列表中的 NSS 标记CMakeLists.txt#L1530。这意味着除非你显式选择 NSS 作为 TLS 后端否则常规构建不受影响。三、gskitIBM 专用 TLS 库后端的移除移除时间线与理由curl 计划在2023 年 8 月移除对gskitTLS 库构建的支持。gskit 是一个小众的 TLS 库只在部分 IBM 系统上运行。文档给出的理由包括没有常规的 curl 贡献者使用该后端没有 CI 构建使用或验证该后端gskit或 curl 对它的适配缺乏许多现代 TLS 特性属于较差的解决方案该代码的构建损坏往往要数周甚至更久才能被发现修复 gskit 代码大多是盲修flying blind。与 NSS 不同gskit 的移除没有设置专门的过渡 configure 开关——它直接进入移除流程。如果你依赖 IBM 平台上的 curlgskit 组合迁移窗口很短需要提前评估其他 TLS 后端如 OpenSSL、GnuTLS、mbedTLS 等的可移植性。四、mingw v1原始遗留 MinGW 构建支持的移除移除时间线与理由curl 计划在2023 年 9 月移除对使用原始遗留的mingw 版本 1构建 curl 的支持。mingw v1 本身已是过时且被弃用的软件文档建议使用仍在维护的 MinGW-w64 作为构建环境。过渡期开关与源码实现在弃用期内可以通过 configure 选项--with-mingw1-deprecated临时启用支持。本仓库 configure.ac#L651-L660 实现了该机制声明--with-mingw1-deprecated帮助文本为 confirm you realize support for mingw v1 is dying在其上方的 configure.ac#L627-L639 中通过编译测试检测原始 MinGW而非 MinGW-w64其判断依据是_mingw.h中是否定义了__MINGW64_VERSION_MAJOR若未定义则判定为原始 MinGW检测到原始 MinGW 而未声明过渡开关时configure 报错support for mingw v1 is going away, enable temporarily with --with-mingw1-deprecated对 Windows 上的开发者而言结论很明确应当迁移到 MinGW-w64 工具链而不是继续依赖已停止维护的 mingw v1。五、空格分隔的NOPROXY模式行为兼容性的移除背景三种设置入口当为 curl 指定不应走代理的域名/模式时存在三处等价的设置入口入口类型说明--noproxycurl 命令行选项工具级见 noproxy.dNO_PROXY环境变量库级环境变量见 libcurl-env.3CURLOPT_NOPROXYlibcurl 选项编程接口见 CURLOPT_NOPROXY.3这三者设置的是同一份模式列表。这份列表被文档化地规定为逗号分隔comma-separated的名称集合但历史上也允许只用空格分隔。用空格作为分隔符的能力从未被官方文档记载过但部分用户可能已经悄悄依赖了这一行为。为什么空格分隔需要移除文档给出的核心论据是可移植性其他许多工具和实用程序也会解析NO_PROXY环境变量但其中不少并不把空格视为合法分隔符。使用空格作为分隔符可能带来更多摩擦而逗号则被更广泛地接受。因此用户应当改用逗号分隔以获得更强的可移植性curl 将在2024 年 7 月移除对空格分隔名称的支持。源码层面的实现与测试证据本仓库lib/noproxy.c中的Curl_check_noproxy()是解析该列表的核心函数lib/noproxy.c#L122-L264其实现细节印证了文档描述解析循环按跳过空白 → 读取 token直到空白或逗号→ 判断匹配进行当读取完一个模式后若下一个字符不是逗号而是空白则把*spacesep置为TRUElib/noproxy.c#L253-L256即代码能够识别并标记该列表使用了空格分隔函数还支持*通配匹配所有主机、域名精确匹配/尾缀匹配忽略首尾点号以及 IPv4/IPv6 的 CIDR 匹配Curl_cidr4_match/Curl_cidr6_matchlib/noproxy.c#L45-L110。CIDR 支持自 7.86.0 起可用参见 noproxy.d#L23-L26。单元测试 unit1614.c 直接验证了这一行为测试表struct noproxy list[]中的用例同时断言是否匹配与是否空格分隔两个结果例如{ www.example.com, localhost .example.com .example.de, TRUE, TRUE }—— 空格分隔列表匹配成功且被标记为空格分隔{ www.example.com, localhost,.example.com,.example.de, TRUE, FALSE }—— 逗号分隔列表匹配成功且未被标记为空格分隔unit1614.c#L80-L89。测试循环还会检查spacesep输出与预期是否一致unit1614.c#L146-L159为后续移除该行为提供了明确的回归基线。迁移建议从现在开始就将NO_PROXY/CURLOPT_NOPROXY/--noproxy中的分隔符统一改为逗号。例如# 不推荐空格分隔将在 2024 年 7 月失效 export NO_PROXYlocalhost .example.com # 推荐逗号分隔可移植且为文档规定的格式 export NO_PROXYlocalhost,.example.com # 命令行等价写法 curl --noproxy localhost,.example.com http://example.com同时注意noproxy.d 还说明了两个相关行为--noproxy自 7.53.0 起会覆盖no_proxy/NO_PROXY环境变量将列表设为可反制环境变量的禁用效果仅有的通配符是单个*字符匹配所有主机即等效于禁用代理。六、过往已移除项回顾清单末尾列出了一批已经完成移除的项目供读者理解 curl 的演进历史Pipelining—— HTTP 管线化axTLS—— 轻量级 TLS 库后端PolarSSL—— TLS 库后端后被 mbedTLS 取代NPN—— Next Protocol NegotiationHTTP/2 协商旧机制已被 ALPN 取代对无 64 位数据类型系统的支持。这些项目的移除印证了 curl 持续清理过时技术、收紧构建矩阵的维护策略。结合本仓库的构建配置third_party/curl/BUILD.gn与 CMakeLists.txt可以看出curl 在现代构建系统中默认启用的都是经过长期维护、有 CI 覆盖的后端组合。七、对本仓库使用者的实际影响本仓库将 curl 作为第三方依赖内嵌主要用于 HTTP 客户端能力结合core/与server/中的相关实现。对绝大多数构建场景而言上述四项弃用特性都不会被默认触发NSS / gskit / mingw v1均属于可选后端或特定平台工具链范畴只有在你显式选择它们时才相关默认构建不受影响空格分隔的NOPROXY属于行为兼容性层面任何依赖该非文档化行为的脚本或调用应在 2024 年 7 月前改用逗号分隔以保证在 curl 移除该行为后依然工作若你的环境恰好使用了 NSS 或原始 MinGW需要尽快评估迁移路径或在过渡期内显式添加--with-nss-deprecated/--with-mingw1-deprecated继续构建。整体而言这份清单的价值在于提前沟通curl 在真正移除前给出明确的日期、理由和过渡开关这份文档正是下游集成方包括本仓库这样的第三方内嵌场景评估依赖风险的第一手依据。赞分享人工智能AI Agent多模态语音AI 应用【免费下载链接】ten-frameworkOpen-source framework for conversational voice AI agents项目地址https://gitcode.com/TEN-framework/ten-framework点击查看免费下载相关推荐Erlang/OTP 30 移除计划详解Guard 类型测试别名、分布式协议与加密组件弃用清单Erlang/OTP 30 移除计划详解Guard 类型测试别名、分布式协议与加密组件弃用清单 本指南基于 Erlang/OTP 仓库中的 OTP 30 计划编程语言语言运行时标准库编译器并发编程CPython 3.14 待移除特性清单12 项标准库弃用移除的完整解读与迁移指南CPython 3.14 待移除特性清单12 项标准库弃用移除的完整解读与迁移指南 CPython 官方通过 Doc/deprecations/ 目录下的清单编程语言语言运行时解释器标准库TEN-framework 内置 curl 的 checksrc 源码风格检查工具全解析警告清单、忽略机制与实战用法TEN framework 内置 curl 的 checksrc 源码风格检查工具全解析警告清单、忽略机制与实战用法 导读 checksrc 是 curl 项人工智能AI Agent多模态语音AI 应用上一篇NextJS与OpenAI Structured Outputs集成指南构建现代化AI应用的最佳实践下一篇终极Android视频处理方案Android-Video-Trimmer核心功能解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考