我正在制作一個使用 express 的長輪詢的聊天應用程式（我知道 websockets 對此更好，我只是想專門用長輪詢來做一些事情）。
這是客戶端GET在等待新聊天訊息時向其發送請求的代碼：
app.get('/api',(req,res)=>{
listeners.push(res)
})
它將回應物件推送到一個陣列，一旦有新的聊天訊息可用，它就會呼叫.send()回應。當客戶端收到回應時，它會再次發送GET請求，等待新訊息。
這是某人發送訊息時的代碼（簡化）
app.post('/api', (req,res)=>{
listeners.forEach(listener=>{
listener.json(req.body)
})
listeners = []
res.status(200).end()
})
我注意到，當我打開網站的兩個選項卡時，首先只有第一個選項卡的請求被放入陣列中。這使得第二個選項卡不會收到第一條聊天訊息。第二個選項卡的請求僅在第一條聊天訊息之后被推送到陣列中。因此，當發送第二條聊天訊息時，它作業正常。這意味著第二個選項卡總是落后一個請求。
如果不清楚，這是一個示例：
Client 1 connects
Client 2 connects
---
Client X sends a message:
Client 1's request 1 receives the message
Client 2's request 1 is still pending
---
Client X sends another message
Client 1's request 2 receives the message
Client 2's request 1 receives the message
---
Client X sends another message
Client 1's request 3 receives the message
Client 2's request 2 receives the message
...
我注意到的另一件事是，當我在客戶端 1 和 2 連接后重新啟動服務器時，客戶端 2 的請求在重新啟動后被推送到陣列中。
有人可以解釋這種行為嗎？提前致謝。
uj5u.com熱心網友回復：
這聽起來像是瀏覽器希望使用快取的請求，因此它會等待具有完全相同 URL 的先前請求，以查看它是否可以使用快取的結果，而不是再次觸發相同的請求。
您可以通過向每個請求添加一個唯一的查詢引數來測驗這個假設，因為這將禁用任何快取嘗試，因為它們都是不同的 URL。
或者，如果這些請求是使用fetch()瀏覽器中的 api 發送的，您可以通過如下選項直接告訴該 API 不使用快取cache: 'no-cache'：
const response = await fetch(url, {cache: 'no-cache'});
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/485893.html
標籤：javascript 节点.js 表示 http 得到