LLRT项目中Headers类对Set-Cookie头的处理问题分析

在LLRT项目中，Headers类对Set-Cookie头的处理存在一个关键的技术问题。这个问题涉及到HTTP协议规范与实现细节，值得开发者深入理解。

问题背景

HTTP协议中的Set-Cookie头与其他标准HTTP头有着显著不同的处理方式。普通HTTP头在出现多个同名头时，通常会用逗号连接它们的值。然而，Set-Cookie头由于自身特性，不能简单地使用逗号连接。

技术细节分析

Set-Cookie头的特殊性主要体现在两个方面：

1. Cookie值本身不允许包含逗号字符，这与其他HTTP头不同
2. 虽然Cookie值不允许逗号，但Expires属性却必须包含逗号（如"Sun, 10-Nov-2024"这样的日期格式）

这种矛盾导致简单的字符串连接方式在处理多个Set-Cookie头时会存在问题。主流JavaScript运行时环境（如Node.js、Bun和Deno）对此有不同的实现策略：

• Node.js在内部存储时使用逗号连接，但在getSetCookie()方法中返回数组
• Bun在内部直接存储为数组结构
• Deno则只保留最后一个Set-Cookie头

解决方案探讨

LLRT项目当前使用BTreeMap<String, String>结构存储头信息，这在处理Set-Cookie头时显得不够灵活。更合理的方案是引入枚举类型来区分不同类型的头值：

enum HeaderValue {
    Single(String),
    Multiple(Vec<String>),
}

这种设计既能保持现有功能，又能正确处理Set-Cookie头的特殊情况。同时，考虑到HTTP头的顺序在某些场景下也很重要，未来可以考虑改用Vec<(String, HeaderValue)>结构，既保持顺序又支持不同类型的值存储。

实现建议

对于LLRT项目的具体实现，建议采取以下策略：

1. 默认情况下，多个同名头用逗号连接（保持现有行为）
2. 对于Set-Cookie头，特殊处理为存储多个独立值
3. 提供getSetCookie()方法返回数组形式的Set-Cookie值
4. 保持get()方法返回逗号连接的字符串（与其他运行时兼容）

这种实现方式既符合HTTP协议规范，又能与其他主流JavaScript运行时保持行为一致，同时为未来的功能扩展预留了空间。