在 POST 请求中使用查询字符串是一种不好的做法吗？

Question

有一个系统将 POST 请求从前端发送到后端。这些 POST 请求不使用正文将数据传递给服务器；相反，它在 URL 参数中使用查询字符串。

这些请求不发送文件或 JSON，仅发送几个字符串参数。

W3C 没有描述这种情况https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

对 POST 请求使用查询字符串是否是一种不好的做法，是否出于安全、性能或体系结构的原因使用它会产生任何负面影响？

是否有任何约定为不同类型的请求定义正文或查询字符串的用法？

Answer 1

提醒：2014 年，RFC2616 被多个 RFC (7230-7237) 取代。在 POST 请求中使用查询字符串是一种不好的做法吗？如果您知道自己在做什么，则不会。从机械上讲，一切都很好：我们是否允许将 POST 与包含查询部分的目标 uri 一起使用？是的。我们可以使用带有空请求主体的 POST 吗？是的。我们可以同时做这两件事吗？是的。困难的部分：此 POST 请求是否会使缓存中的正确表示无效？当服务器对不安全请求（POST 是一种不安全请求方法）返回非错误响应时，就会发生缓存失效。无效的表示是那些匹配不安全请求的目标 uri 的表示。GET /foo?a=b HTTP/2.0 POST /foo?a=b HTTP/2.0这里，如果 POST 成功，则 GET 请求成功后缓存的表示将在缓存中失效。GET /foo HTTP/2.0 POST /foo?a=b HTTP/2.0在这里，有效的请求 uri 是不一样的，这意味着通用组件不会使缓存的/foo.

Answer 2

在 POST 请求的 URL 中使用查询参数没有任何问题，无论是否有请求主体。如果它对您的请求具有语义意义，那很好。POST 方法本身具有与 GET 不同的语义含义，它不需要请求主体才有用，而且 URL 也与此不同。一个经典的例子可能是：POST /foo/bar?token=83q2fn2093c8jm203即，通过 URL 传递某种令牌。这里没有一般的安全问题，因为任何可以拦截此 POST 请求以读取 URL 的人也可以读取其正文数据；你很难找到一个允许他们读取 URL 而不是正文的攻击者。但是，URL 通常会记录在服务器访问日志和浏览器历史记录中，而请求主体则不会；这可能值得考虑也可能不值得考虑，具体取决于您在这些参数中传输的信息以及谁有权访问这些日志。