有一个系统将 POST 请求从前端发送到后端。这些 POST 请求不使用正文将数据传递给服务器；相反，它在 URL 参数中使用查询字符串。
这些请求不发送文件或 JSON，只发送几个字符串参数。
W3C 没有描述这种情况https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
将查询字符串用于 POST 请求是否是一种不好的做法，以及是否出于安全、性能或架构原因使用它会产生任何负面影响？
是否有任何约定为不同类型的请求定义正文或查询字符串的使用？
【问题讨论】：
标签： javascript forms rest post networking
提醒：2014 年，RFC2616 was replaced by multiple RFCs (7230-7237)。
在 POST 请求中使用查询字符串是一种不好的做法吗？
如果你知道自己在做什么，就不会。
从机械上讲，一切都很好：我们是否允许将 POST 与包含查询部分的目标 uri 一起使用？是的。我们是否允许使用带有空请求正文的 POST？是的。我们可以同时做这两件事吗？是的。
困难的部分：这个 POST 请求会使缓存中的正确表示无效吗？
Cache-invalidation 发生在服务器对unsafe 请求返回非错误响应时（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
这里，有效的request-uri不一样，这意味着通用组件不会使/foo的缓存表示无效。
【讨论】：
在 POST 请求的 URL 中使用查询参数没有任何问题，无论是否带有请求正文。如果它对您的请求具有语义意义，那很好。 POST 方法本身具有与 GET 不同的语义含义，它不需要请求主体是有用的，并且 URL 又与此不同。一个经典的例子可能是：
POST /foo/bar?token=83q2fn2093c8jm203
即，通过 URL 传递某种令牌。
这里没有一般的安全问题，因为任何可以拦截此 POST 请求以读取 URL 的人也可以读取其正文数据；您几乎不会发现攻击者处于允许他们读取 URL 而不是正文的位置。但是，URL 通常会记录在服务器访问日志和浏览器历史记录中，而请求正文则不会；这可能值得考虑，也可能不值得考虑，具体取决于您在这些参数中传输的信息以及谁有权访问这些日志。
【讨论】：
you'll hardly find an attacker in a position that allows them to read the URL but not the body 并且这对于 HTTPS 安全通信是正确的。但不是一般的，虽然。一旦数据到达网络服务器日志，它们就会在那里停留一段时间，直到它们被轮换。同样，如今，日志通常被传递给一些分析，因此它们在基础设施中四处移动，并且有许多潜在的地方可能会泄漏。另一方面，请求正文根本不应该被记录，因此一旦网络服务器处理完请求，它就消失了。