1998 年 10 月， curl 4.9 发布了，curl 4.9 是第一个带有 “cookie 引擎” 的版本，可以接收 HTTP cookie、解析、理解并在后续请求中正确返回 cookie。

当然，当时 curl 的受众很小，几个月后 curl 网站才宣布 curl l 4.9 版本的下载量达到了 300 次。而且当时 cookie 也没有明确的规范，唯一描述 cookie 如何工作的规范是 Netscape 网景公司一个非常简短的文档，名为 cookie_spec。

在随后的日子里，IETF（互联网工程任务组） 一直在努力创建 cookie 规范，但大多失败了。因为 Cookie 有点特别，它们由许多不同的作者、代码库和网站实现，从根本上改变 “从上而下的规范” 的工作方式。

直到 2011 年发布的 Cookie RFC 6265，这是真正意义上的 Cookie 规范，解释了 cookie 是什么，以及应该遵守什么。但这也引来了一些问题，RFC 6265 为服务器如何发送 cookie 提供了一种字段语法，而为客户端提供了一种截然不同的语法用来接受 cookie。双重语法导致了两个问题：

很难阅读规范，因为很容易陷入其中一种语法，并假设语法对所有用例有效。

定义发送 cookie 的语法没什么用，因为客户端才是真正决定如何接收和处理 cookie 。现有的大型 cookie 解析器（如浏览器）在接受的内容格式上相当自由，没有人注意服务器是否遵循 RFC 规范中的语法。

随着时间的推移， cookie 的发展依然缓慢，但 HTTP 规范在过去的几十年中已经更新了很多次。更重要的是 HTTP 服务器实现已经实施了更严格的解析策略：如果传入的 HTTP 请求看起来 “非法” 或格式不正确，HTTP 服务器开始提前拒绝它们。现在尝试向一个新的 HTTP 服务器发送一个包含控制代码的请求，那么服务器只会拒绝该请求并返回一个 400 响应代码。

一个 23 年的 Bug

2022 年 6 月末，curl 收到了一份关于 curl 可疑安全问题的报告，这导致 curl 随后发布了 CVE-2022-35252。

事实证明，1998 年的 curl  cookie 代码接受包含控制代码的 cookie。控制代码可以是名称或内容的一部分，如果用户启用 “cookie 引擎”，curl 将存储这些 cookie ，并在后续请求中将它们返回。比如：

Set-Cookie: name^a=content^b; domain=.example.com

^a 和 ^b 代表控制码，字节码一和二。由于域可以将 cookie 标记为另一个主机。因此，该 cookie 将包含在对该域内所有主机的请求中。当 curl 将这样的 cookie 发送到 HTTP 服务器时，它会在传出请求中包含这样的标头字段：

Cookie: name^a=content^b

而默认配置的服务器将响应 400。对于接收这些 cookie 的脚本或应用程序，只要 cookie 继续发送，进一步的请求将被拒绝，形成拒绝服务 DOS 攻击。

自 4.9 版本以来（curl 项目开发的第 201），这些易受攻击的 cookie 代码就一直存在于 curl 里面，直到 7.85.0 版本（curl 项目开发的第 8930 天）才得到修复，中间经历了 8729 天（23.9 年）。

当然，据 Daniel 解释：这些 cookie 代码当初发布时没有问题，并且在用户使用的大部分时间里也没有问题。且最新版本的 curl 已经完全符合最新的 RFC 6265bis 草案版本的规定。