當前位置：首頁 > news >正文

日本做曖小視頻在線觀看網(wǎng)站百度app下載安裝官方

news 2025/7/7 13:56:44

日本做曖小視頻在線觀看網(wǎng)站,百度app下載安裝官方,響應式網(wǎng)站建設過時嗎,動漫wordpress在 Tubi，我們使用 Node.js 為 Web/OTT 應用進行服務端渲染及代理請求。近來，為了從新版本的性能改進和新功能中受益，我們將 Node.js 從 14.x 版本升級到了 20.x。升級像 Node.js 這樣的基礎設施絕非易事，尤其是有著許多第三方依…

在 Tubi，我們使用 Node.js 為 Web/OTT 應用進行服務端渲染及代理請求。近來，為了從新版本的性能改進和新功能中受益，我們將 Node.js 從 14.x 版本升級到了 20.x。

升級像 Node.js 這樣的基礎設施絕非易事，尤其是有著許多第三方依賴的大型項目，因為我們無法預測可能會出現(xiàn)的問題。在升級過程中，我們很快便遇到了第一個問題：服務器端發(fā)送的每個請求都會失敗，并返回 404 的錯誤。

調(diào)試

第一個被懷疑的對象是倉庫里已經(jīng)逐漸被我們棄用的 request 庫。我們在 Node.js 20 環(huán)境下使用 request 庫發(fā)送請求復現(xiàn)了該問題：request.get('https://foo.bar/get')，服務端返回了包括 404 響應在內(nèi)的多種錯誤。該庫使用了 Node.js 內(nèi)置的?http(s) 模塊來發(fā)送請求。為了探究發(fā)送請求時究竟發(fā)生了什么，我們又給測試添加了NODE_DEBUG=http,net 和 -trace-event-categories node.http,node.net.native 標志。

{"cat":"node,node.http","name":"http.client.request","args":{"data":{"path":"/"}}}

以下是我們的發(fā)現(xiàn)：

我們請求的是?https://foo.bar/get，但 http.request 的 path 卻是 /。
如果我們將 Node.js 降級到 14 版本并使用同樣的代碼，path 的值則是正確的 /get。這解釋了為什么服務器返回了 404 響應。

我們嘗試在 Node.js 20 版本下構造兩個最小復現(xiàn)案例: 一個案例采用了原生的 Node.js 模塊 http，另一個案例使用了 request 庫；但這兩個案例都無法復現(xiàn)這一異常情況。這讓我們開始懷疑，我們的代碼庫中是否有可能存在問題？

在深入研究代碼庫之前，我們在該庫 GitHub 的 issues 中發(fā)現(xiàn)了一個類似問題，其中提到了該問題可能與用于追蹤錯誤的?Sentry?SDK 有關。我們通過在 Node.js 20 中引入 Sentry 和該庫成功地復現(xiàn)了這一問題。那么，為什么 Request 庫 + Sentry + Node.js 20 會導致這一問題出現(xiàn)？我們來看看它們分別對 Node.js 的 http(s) 模塊做了什么。

調(diào)試內(nèi)置的 Node.js 模塊

為了檢查傳遞給 Node.js 內(nèi)置 http(s) 模塊的真實參數(shù)，我們通過在命令中添加了 -expose-internals 參數(shù)（以及 -r internal/test/binding 標志來訪問 primordials），并從?Node.js 代碼庫中復制了 http(s) 模塊文件：

// 將 
const https = require('https');
// 修改為
const https = require('./path/to/local/https');

現(xiàn)在我們可以打印日志、添加斷點了，還可以直接修改模塊代碼。我們還發(fā)現(xiàn)了更多線索：http(s) 模塊接受?WHATWG URL 對象或一個普通對象作為參數(shù)。在我們的案例中，request 庫將一個普通對象作為參數(shù)發(fā)送給 http(s) 模塊，但由于某種原因，http(s) 模塊將其視為了 URL 對象。而如果它是一個 URL 對象，Node.js 會將其轉換為 http(s) 需要的參數(shù)，并將 path 設置為 URL.pathname + URL.search。而這個庫傳遞的對象上不存在這些屬性，于是導致了真正發(fā)出的請求中 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 函數(shù)中，如果在參數(shù)中找到 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 庫的源代碼，發(fā)現(xiàn) request 庫添加了 href 屬性，而 Sentry?添加了 protocol 屬性。

謎團終于解開了！

如何修復這一問題？

我們理解了造成 404 錯誤的原因，也很清楚因為 request 庫、Sentry 和 Node.js 都存在各自的問題，所以修復這一問題將變得十分棘手；但問題的根源在于 Node.js 方面：isURL 函數(shù)無法準確判斷是否為 URL 對象。因此，我們必須找到一種準確判斷 URL 對象的方法。這應該不會太難吧？

我們可以直接使用 object instanceof URL 嗎？很遺憾，結果是不行，因為它無法識別來自其他實現(xiàn)（例如 Electron）的 URL 對象。
我們是否可以檢查其他屬性，或者將屬性從 protocol 改回 origin 呢？雖然我們可以這樣做，但這并不是一個最理想的解決方案，因為其他屬性可能會引起性能問題。

我們無法找到一個最直接的解決方案，但我們注意到 isURL 函數(shù)上的另一個檢查 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 版本中發(fā)布！對于那些繼續(xù)使用 v18.x 的用戶，這一修復方案很可能也會在?v18.18.0 版本中提供！