景县网站建设公司,网站诊断工具,wordpress模版做网页,分类信息网站程序在 Tubi#xff0c;我们使用 Node.js 为 Web/OTT 应用进行服务端渲染及代理请求。近来#xff0c;为了从新版本的性能改进和新功能中受益#xff0c;我们将 Node.js 从 14.x 版本升级到了 20.x。
升级像 Node.js 这样的基础设施绝非易事#xff0c;尤其是有着许多第三方依…在 Tubi我们使用 Node.js 为 Web/OTT 应用进行服务端渲染及代理请求。近来为了从新版本的性能改进和新功能中受益我们将 Node.js 从 14.x 版本升级到了 20.x。
升级像 Node.js 这样的基础设施绝非易事尤其是有着许多第三方依赖的大型项目因为我们无法预测可能会出现的问题。在升级过程中我们很快便遇到了第一个问题服务器端发送的每个请求都会失败并返回 404 的错误。
调试
第一个被怀疑的对象是仓库里已经逐渐被我们弃用的 request 库。我们在 Node.js 20 环境下使用 request 库发送请求复现了该问题request.get(https://foo.bar/get)服务端返回了包括 404 响应在内的多种错误。该库使用了 Node.js 内置的 http(s) 模块来发送请求。为了探究发送请求时究竟发生了什么我们又给测试添加了NODE_DEBUGhttp,net 和 -trace-event-categories node.http,node.net.native 标志。
{cat:node,node.http,name:http.client.request,args:{data:{path:/}}}
以下是我们的发现
我们请求的是 https://foo.bar/get但 http.request 的 path 却是 /。如果我们将 Node.js 降级到 14 版本并使用同样的代码path 的值则是正确的 /get。这解释了为什么服务器返回了 404 响应。
我们尝试在 Node.js 20 版本下构造两个最小复现案例: 一个案例采用了原生的 Node.js 模块 http另一个案例使用了 request 库但这两个案例都无法复现这一异常情况。这让我们开始怀疑我们的代码库中是否有可能存在问题
在深入研究代码库之前我们在该库 GitHub 的 issues 中发现了一个类似问题其中提到了该问题可能与用于追踪错误的 Sentry SDK 有关。我们通过在 Node.js 20 中引入 Sentry 和该库成功地复现了这一问题。那么为什么 Request 库 Sentry Node.js 20 会导致这一问题出现我们来看看它们分别对 Node.js 的 http(s) 模块做了什么。
调试内置的 Node.js 模块
为了检查传递给 Node.js 内置 http(s) 模块的真实参数我们通过在命令中添加了 -expose-internals 参数以及 -r internal/test/binding 标志来访问 primordials并从 Node.js 代码库中复制了 http(s) 模块文件
// 将
const https require(https);
// 修改为
const https require(./path/to/local/https);
现在我们可以打印日志、添加断点了还可以直接修改模块代码。我们还发现了更多线索http(s) 模块接受 WHATWG URL 对象或一个普通对象作为参数。在我们的案例中request 库将一个普通对象作为参数发送给 http(s) 模块但由于某种原因http(s) 模块将其视为了 URL 对象。而如果它是一个 URL 对象Node.js 会将其转换为 http(s) 需要的参数并将 path 设置为 URL.pathname URL.search。而这个库传递的对象上不存在这些属性于是导致了真正发出的请求中 path 为空
// The request function that http(s) module use:
// https://github.com/nodejs/node/blob/36c72c8b2fb03414e02ffd8402c05129647ce123/lib/https.js#L367C5-L369
function request(...args) {...if (isURL(args[0])) {options urlToHttpOptions(ArrayPrototypeShift(args));}
}
// https://github.com/nodejs/node/blob/36c72c8b2fb03414e02ffd8402c05129647ce123/lib/internal/url.js#L1322C1-L1344
function urlToHttpOptions(url) {const { pathname, search } url;const options {...path: ${pathname || }${search || },}return options
}
那为什么 http(s) 模块会将来自该库的普通对象认为是一个 URL 对象呢在 isURL 函数中如果在参数中找到 href 和 protocol 字段则会认为其是一个 URL 对象
// https://github.com/nodejs/node/blob/36c72c8b2fb03414e02ffd8402c05129647ce123/lib/internal/url.js#L761
function isURL(self) {return Boolean(self?.href self.protocol self.auth undefined);
}
那么这两个属性是如何被添加到传递给 http(s) 模块的对象上的呢我们检查了库和 Sentry 库的源代码发现 request 库添加了 href 属性而 Sentry 添加了 protocol 属性。
谜团终于解开了
如何修复这一问题
我们理解了造成 404 错误的原因也很清楚因为 request 库、Sentry 和 Node.js 都存在各自的问题所以修复这一问题将变得十分棘手但问题的根源在于 Node.js 方面isURL 函数无法准确判断是否为 URL 对象。因此我们必须找到一种准确判断 URL 对象的方法。这应该不会太难吧
我们可以直接使用 object instanceof URL 吗很遗憾结果是不行因为它无法识别来自其他实现例如 Electron的 URL 对象。我们是否可以检查其他属性或者将属性从 protocol 改回 origin 呢虽然我们可以这样做但这并不是一个最理想的解决方案因为其他属性可能会引起性能问题。
我们无法找到一个最直接的解决方案但我们注意到 isURL 函数上的另一个检查 self.auth undefined 解决了类似的问题这就是为什么我们添加了遗留的 URL 对象属性 self.path undefined: path而非 WHATWG URL 对象属性。通过验证 path 是否为 undefined 来确定是否为 WHATWG URL 对象这是更合理的。在我们的案例中path不是 undefined这意味着该对象不是 WHATWG URL 对象。
于是我们决定在 GitHub 上开启了一个讨论提交一个包含修复方案的 Pull Request并对 Yagiz Nizipli 的这一评论做了深入思考“这有点像鸡生蛋还是蛋生鸡的问题我们既不能检查 URL 对象也不能正确检查 url。我们唯一能做的就是检查它们的行为 / 定义。”
好消息是我们提出的修复方案将在 v20.6.0 版本中发布对于那些继续使用 v18.x 的用户这一修复方案很可能也会在 v18.18.0 版本中提供
总结
Node.js、 request 库和 Sentry 库的变化导致 http(s) 模块误将一个普通对象识别为 URL 对象这就是 http(s) 模块重置了 path 并引发了问题的原因。以下是 Node.js 和这两个库近期实现的一些变更
Node.js 近期实现了将 URL 对象的检测从带有 origin 和 href 改为带有 protocol 和 href 以提高性能。Request 库向 http(s) 模块的请求选项中添加了 href 属性或许是为了调试目的。Sentry 库中添加了一个 protocol 属性以修复一个 bug。
我们的收获
我们在解决了 Node.js 20 升级中出现的意外请求问题后希望与大家分享这样几点收获
分而治之
由多个第三方库交互而引发的问题可能很难调试与修复但有一种方法是从底层开始逐步追踪问题的源头将其分解为更小的问题以更容易处理。
避免使用已弃用的库
这相当于在代码中放置了一个定时炸弹它最终一定会爆炸。我们在实践中便遇到了这一问题。我们有计划替换已弃用的库但在工作完成之前这一定时炸弹就爆炸了。
避免 patch 原生模块
在 Node.js 上 patch 原生模块如 http(s)会使调试变得更加困难尤其是对于第三方库工程师们应避免这种做法。
有时我们无法找到最完美的解决方案我们能做的就是全力以赴。
Tubi 正在招聘
如你所见Tubi 技术团队成功解决了在 Node.js 20 升级过程中出现的未预期的请求问题。我们快速锁定了由第三方依赖引起的 URL 对象检测变化是这一问题的根源。如果你和我们一样对这一类问题的解决感兴趣欢迎加入我们
Tubi 技术团队正在招聘点击此处可查看 Tubi 的热招岗位。
作者Zhuo Zhang, Tubi Senior Software Engineer
