带有请求主体的HTTP GET

我正在为我们的应用程序开发一个新的RESTful Web服务。

当对某些实体执行GET时，客户端可以请求实体的内容。如果他们想添加一些参数（例如排序列表），可以在查询字符串中添加这些参数。

或者，我希望人们能够在请求主体中指定这些参数。HTTP/1.1似乎并没有明确禁止这一点。这将允许他们指定更多信息，可能会更容易指定复杂的XML请求。

我的问题：

这完全是个好主意吗？HTTP客户端在GET请求中使用请求体时会遇到问题吗？

https://www.rfc-editor.org/rfc/rfc2616

当前回答

如果您真的想将可计算的JSON/XML正文发送到web应用程序，那么放置数据的唯一合理位置是使用RFC4648:Base64Encoding和URL和文件名安全字母表编码的查询字符串。当然，您可以只对JSON进行URL编码，并将其放入URL参数的值中，但Base64给出的结果较小。请记住，URL大小有限制，请参阅不同浏览器中URL的最大长度是多少。

您可能会认为Base64的padding=字符可能对URL的参数值有害，但这似乎不是-请参阅以下讨论：http://mail.python.org/pipermail/python-bugs-list/2007-February/037195.html . 但是，您不应该将编码数据放在没有参数名称的位置，因为带填充的编码字符串将被解释为具有空值的参数键。我会用类似的东西_b64=<编码器数据>。

2013-02-18 13:43:58

其他回答

不符合base64编码的标头怎么办？“某些参数：sdfSD45fdg45/aS”

长度限制hm.你不能让POST处理区分含义吗？如果你想要像排序这样的简单参数，我不明白为什么这会是一个问题。我想你肯定担心。

2011-02-15 21:34:57

罗伊·菲尔丁（Roy Fielding）关于在GET请求中包含身体的评论。

对换句话说，任何HTTP请求消息都允许包含消息体，因此必须考虑到这一点来解析消息。然而，GET的服务器语义受到限制，使得主体（如果有的话）对请求没有语义意义。解析的需求与方法语义的需求是分开的。所以，是的，你可以用GET发送一个身体，但不，这样做从来都没有用。这是HTTP/1.1分层设计的一部分，一旦规范被划分（正在进行中），分层设计将再次变得清晰。……罗伊

是的，您可以用GET发送请求体，但它应该没有任何意义。如果您通过在服务器上解析它并根据其内容更改响应来赋予其含义，那么您将忽略HTTP/1.1规范第4.3节中的建议：

…如果请求方法不包含实体体的定义语义，则在处理请求时应忽略消息体。

以及HTTP/1.1规范第9.3节中GET方法的描述：

GET方法意味着检索请求URI标识的任何信息（[…]）。

其声明请求主体不是GET请求中的资源标识的一部分，而是请求URI。

使现代化

被称为“HTTP/1.1规范”的RFC2616现在已经过时。2014年，它被RFC7230-7237取代。引号“处理请求时应忽略消息正文”已删除。现在只是“请求消息框架独立于方法语义，即使该方法没有定义消息体的任何用途”第二个引号“GET方法意味着检索任何信息……由请求URI标识”被删除。-来自评论

根据HTTP 1.1 2014规范：

GET请求消息中的有效负载没有定义的语义；在GET请求上发送有效负载主体可能会导致一些现有实现拒绝该请求。

2009-06-11 20:27:36

我向IETF HTTP工作组提出了这个问题。Roy Fielding（1998年，http://1.1文档的作者）的评论是

“…一个实现将被破坏，无法执行除解析和丢弃该主体之外的任何操作”

RFC 7213（HTTPbis）规定：

“GET请求消息中的有效负载没有定义的语义；”

现在看来很明显，其意图是禁止GET请求体上的语义，这意味着请求体不能用于影响结果。

如果你在GET上包含一个主体，那么有一些代理肯定会以各种方式破坏你的请求。

总之，不要这样做。

2016-07-28 01:06:25

restclient和REST控制台都不支持这一点，但curl支持。