似乎表達的默認行為是規范化包含向上目錄 (/../) 的 URL
對于下面的代碼，如果我請求這樣的 URL
http://localhost:8080/foo/../../bar
請求被重定向到
http://localhost:8080/bar
我找不到有關此行為的任何詳細檔案。
我的問題是：
- 是有保證的行為嗎
- 如果我不是從檔案系統提供服務，有沒有辦法在我使用其他處理的情況下保留原始 URL“路徑”？
經過
const express = require("express")
const app=express()
app.get("/*", (req,res) => {
console.log("url:",req.url);
console.log("path:",req.path);
res.send('echo for url=' req.url '; path=' req.path')
}
const port=8080;
app.listen(port,() =>{
console.log(`listening on port ${port}`);
});
uj5u.com熱心網友回復：
請求不會被重定向，而是客戶端在發出請求之前重建 URL
>curl -v http://localhost:8080/foo/../../bar
* Rebuilt URL to: http://localhost:8080/bar
因此，服務器永遠不會看到“原始 URL 路徑”。
此 URL 重建是決議程序的一部分。另請參閱https://url.spec.whatwg.org/#concept-basic-url-parser。
然而，惡意客戶端（例如，telnet 客戶端）可以發送帶有“未決議”URL 的 HTTP 請求。以下中間件演示了如何在服務器上重建 URL：
function(req, res) {
res.json({path: req.path,
rebuilt_path: new URL("s://" req.path).pathname});
}
惡意請求
GET /foo/../../bar HTTP/1.1
Host: localhost:8080
然后回傳
{"path": "/foo/../../bar", "rebuilt_path": "/bar"}
（如果req.baseUrl也涉及，事情會變得更加復雜。）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/406244.html
標籤：