trpc项目中EventSource Polyfill的授权头更新问题解析

背景介绍

在现代Web开发中，实时数据推送变得越来越重要。trpc作为一个全栈TypeScript框架，提供了unstable_httpSubscriptionLink功能来实现基于HTTP的订阅机制。这个功能底层使用了EventSource（服务器发送事件）技术，而在不支持原生EventSource的浏览器环境中，则需要使用EventSource polyfill。

核心问题

当使用EventSource polyfill时，存在一个关键的技术限制：授权头信息（如Authorization头）只在EventSource实例初始化时被设置一次。这意味着：

1. 如果连接中断后自动重连，polyfill会使用初始的授权头信息
2. 如果授权令牌在此期间已过期，系统将无法自动更新令牌
3. 导致用户即使重新登录也无法恢复连接

技术原理分析

原生EventSource规范本身不支持动态修改请求头，这是出于安全考虑的设计。polyfill实现通常遵循这一规范，因此也继承了这一限制。但在实际应用中，这会导致：

• 短生命周期令牌场景下的连接问题
• 需要重新加载页面才能恢复连接的不良用户体验
• 无法利用现代应用常见的令牌刷新机制

trpc的解决方案

trpc团队提出了一个优雅的解决方案，通过引入shouldRecreate回调函数来智能控制EventSource实例的重建：

unstable_httpSubscriptionLink({
  eventSourceOptions() {
    return {
      headers: {
        Authorization: `Bearer ${getToken()}`
      }
    }
  },
  shouldRecreate(event) {
    // 在401/403状态码时重建EventSource
    return [401, 403].includes(event.status)
  }
})

这个方案具有以下技术优势：

1. 精确控制：开发者可以基于错误类型决定是否重建连接
2. 异步支持：支持返回Promise，便于执行异步操作如令牌刷新
3. 性能优化：避免了不必要的实例重建
4. 向后兼容：不影响现有实现

实现细节

在底层实现上，trpc处理了几种关键情况：

1. 错误处理：捕获连接错误并触发回调
2. 并发控制：防止多个重建请求同时执行
3. 资源清理：确保旧的EventSource实例被正确销毁
4. 状态恢复：重建后保持订阅的连续性

最佳实践建议

基于这一特性，开发者可以：

1. 结合令牌刷新机制实现无缝认证
2. 根据业务需求扩展重建条件
3. 添加适当的重试限制和回退策略
4. 在UI层提供连接状态反馈

总结

trpc通过这一改进，巧妙地绕过了EventSource polyfill的限制，为开发者提供了更强大的实时数据管理能力。这种解决方案不仅解决了授权头更新的问题，还建立了一个可扩展的错误处理框架，值得在其他类似场景中借鉴。