SolidStart 中 Server Action 返回的 Set-Cookie 头被覆盖问题解析

在 SolidStart 框架中，开发者使用服务器动作（Server Action）时可能会遇到一个特殊问题：当在无 JavaScript 环境下运行时，服务器动作返回的 set-cookie 头会被框架自动生成的 flash cookie 覆盖。这个问题主要影响那些需要在服务器动作中设置自定义 cookie 的开发场景。

问题现象

当开发者通过服务器动作返回一个带有 set-cookie 头的响应时，例如：

return redirect("/foo", { headers: { "set-cookie": "foo=bar" } })

在无 JavaScript 模式下运行时，客户端最终接收到的响应中，开发者设置的 foo=bar cookie 会被框架自动生成的 flash cookie 覆盖，导致自定义 cookie 无法生效。

技术背景

SolidStart 框架在无 JavaScript 环境下处理服务器动作时，会使用一种特殊的机制来保持状态。当服务器动作执行完毕后，框架会自动生成一个 flash cookie，其中包含了动作执行结果、错误信息等状态数据。这个机制原本是为了在页面重定向后仍能保持服务器动作的执行状态。

问题根源

问题出在框架的 handleNoJS 函数实现上。当前版本的实现中，这个函数会完全覆盖响应头，而不是合并现有的响应头。具体来说：

1. 当服务器动作返回一个 Response 对象时，框架会提取其中的 Location 头用于重定向
2. 然后框架会生成一个新的 Response 对象，其中只包含 Location 头和 flash cookie
3. 原始 Response 中的其他头信息（包括开发者设置的 set-cookie）在这个过程中丢失了

解决方案

社区贡献者提供了一个有效的补丁方案，主要修改了 handleNoJS 函数的实现逻辑：

1. 首先保留原始 Response 中的所有头信息
2. 如果需要重定向，更新 Location 头而不是覆盖所有头
3. 将 flash cookie 作为额外的 set-cookie 头追加到现有头中，而不是替换

这个修改确保了开发者设置的 cookie 能够与框架的 flash cookie 共存，而不是被覆盖。

实际影响

这个问题主要影响以下场景：

• 需要在服务器动作中设置认证或会话 cookie
• 依赖 cookie 传递临时状态信息的应用
• 需要同时使用框架的 flash 机制和自定义 cookie 的情况

对于大多数应用来说，这个问题可能不会立即显现，因为现代浏览器通常都启用了 JavaScript。但在无 JavaScript 或 JavaScript 受限的环境中，这个问题会导致关键功能失效。

最佳实践

在等待官方修复的同时，开发者可以：

1. 使用提供的补丁作为临时解决方案
2. 考虑将关键状态信息同时存储在 flash cookie 中
3. 对于关键功能，确保有 JavaScript 降级方案

这个问题的修复将包含在未来的 SolidStart 版本中，届时开发者将能够直接在服务器动作中设置 cookie 而无需担心被覆盖的问题。