首頁(yè) 猿問在 POST...

在 POST 請(qǐng)求中使用查詢字符串是一種不好的做法嗎？

JavaScript

哆啦的時(shí)光機(jī) 2023-03-24 17:04:36

有一個(gè)系統(tǒng)將 POST 請(qǐng)求從前端發(fā)送到后端。這些 POST 請(qǐng)求不使用正文將數(shù)據(jù)傳遞給服務(wù)器；相反，它在 URL 參數(shù)中使用查詢字符串。這些請(qǐng)求不發(fā)送文件或 JSON，僅發(fā)送幾個(gè)字符串參數(shù)。W3C 沒有描述這種情況https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html對(duì) POST 請(qǐng)求使用查詢字符串是否是一種不好的做法，是否出于安全、性能或體系結(jié)構(gòu)的原因使用它會(huì)產(chǎn)生任何負(fù)面影響？是否有任何約定為不同類型的請(qǐng)求定義正文或查詢字符串的用法？

查看完整描述

2 回答

MYYA

TA貢獻(xiàn)1868條經(jīng)驗(yàn) 獲得超4個(gè)贊

提醒：2014 年，RFC2616 被多個(gè) RFC (7230-7237) 取代。

在 POST 請(qǐng)求中使用查詢字符串是一種不好的做法嗎？

如果您知道自己在做什么，則不會(huì)。

從機(jī)械上講，一切都很好：我們是否允許將 POST 與包含查詢部分的目標(biāo) uri 一起使用？是的。我們可以使用帶有空請(qǐng)求主體的 POST 嗎？是的。我們可以同時(shí)做這兩件事嗎？是的。

困難的部分：此 POST 請(qǐng)求是否會(huì)使緩存中的正確表示無(wú)效？

當(dāng)服務(wù)器對(duì)不安全請(qǐng)求（POST 是一種不安全請(qǐng)求方法）返回非錯(cuò)誤響應(yīng)時(shí)，就會(huì)發(fā)生緩存失效。無(wú)效的表示是那些匹配不安全請(qǐng)求的目標(biāo) uri 的表示。

GET /foo?a=b HTTP/2.0
POST /foo?a=b HTTP/2.0

這里，如果 POST 成功，則 GET 請(qǐng)求成功后緩存的表示將在緩存中失效。

GET /foo HTTP/2.0
POST /foo?a=b HTTP/2.0

在這里，有效的請(qǐng)求 uri 是不一樣的，這意味著通用組件不會(huì)使緩存的/foo.

反對(duì) 回復(fù) 2023-03-24

四季花海

TA貢獻(xiàn)1811條經(jīng)驗(yàn) 獲得超5個(gè)贊

在 POST 請(qǐng)求的 URL 中使用查詢參數(shù)沒有任何問題，無(wú)論是否有請(qǐng)求主體。如果它對(duì)您的請(qǐng)求具有語(yǔ)義意義，那很好。POST 方法本身具有與 GET 不同的語(yǔ)義含義，它不需要請(qǐng)求主體才有用，而且 URL 也與此不同。一個(gè)經(jīng)典的例子可能是：

POST /foo/bar?token=83q2fn2093c8jm203

即，通過 URL 傳遞某種令牌。

這里沒有一般的安全問題，因?yàn)槿魏慰梢詳r截此 POST 請(qǐng)求以讀取 URL 的人也可以讀取其正文數(shù)據(jù)；你很難找到一個(gè)允許他們讀取 URL 而不是正文的攻擊者。但是，URL 通常會(huì)記錄在服務(wù)器訪問日志和瀏覽器歷史記錄中，而請(qǐng)求主體則不會(huì)；這可能值得考慮也可能不值得考慮，具體取決于您在這些參數(shù)中傳輸?shù)男畔⒁约罢l(shuí)有權(quán)訪問這些日志。

反對(duì) 回復(fù) 2023-03-24