Hono.js中WebSocket RPC请求的Cookie处理机制解析

在基于Hono.js 4.6.1构建的Node.js 22应用中，开发者常会遇到WebSocket连接时的Cookie传递问题。本文深入分析该现象的技术原理，帮助开发者理解不同连接方式的差异。

问题现象重现

当开发者通过两种不同方式建立WebSocket连接时：

1. 使用Hono提供的RPC方法.$ws()
2. 直接使用原生WebSocket构造函数

会发现前者仅传递基础Cookie，而后者会携带包括session在内的所有自定义Cookie。这种差异可能导致基于Cookie的WebSocket鉴权机制失效。

技术原理分析

同源策略的影响

浏览器对WebSocket请求实施与HTTP相同的同源策略。关键点在于：

• 127.0.0.1和localhost被浏览器视为不同源
• 端口号必须完全一致
• 协议必须相同（ws/https）

RPC连接的特殊性

Hono的RPC方法在底层会自动处理请求头，但开发者需要注意：

1. 绝对URL vs 相对URL
2. 显式指定的origin会覆盖默认行为
3. 跨域场景下的安全限制

最佳实践方案

1. 统一地址规范：

   • 开发环境建议统一使用localhost域名
   • 生产环境确保前后端域名完全一致

2. 连接方式优化：

// 推荐方式（相对路径）
const ws = new WebSocket('/ws-endpoint')

// 替代方案（确保完全一致的绝对路径）
const ws = new WebSocket('ws://localhost:5173/ws-endpoint')

3. 调试技巧：
   • 使用浏览器开发者工具检查WebSocket连接的Request Headers
   • 特别注意Origin和Cookie头部的差异

深度思考

这个案例揭示了Web开发中容易忽视的基础概念：

• 网络地址的规范化处理
• 浏览器安全策略的实际影响
• 框架抽象层背后的实现细节

理解这些底层机制，能帮助开发者在遇到类似问题时快速定位原因，而不是简单归咎于框架行为异常。