带请求正文的HTTP GET

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

在某些实体上执行GET时，客户端能够请求实体的内容。 若是他们想添加一些参数（例如，对列表进行排序），则能够在查询字符串中添加这些参数。

另外，我但愿人们可以在请求正文中指定这些参数。 HTTP / 1.1彷佛没有明确禁止这样作。 这将使他们可以指定更多信息，可能使指定复杂的XML请求更加容易。

个人问题：

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

http://tools.ietf.org/html/rfc2616

---

#1楼

您能够发送带有主体的GET或发送POST并放弃RESTish宗教信仰（这还不错，五年前，只有一种信仰的人-他的评论在上面连接）。

作出好的决定都不是，可是发送GET正文可能会防止某些客户端和某些服务器出现问题。

使用某些RESTish框架进行POST可能会遇到障碍。

朱利安·雷施克（Julian Reschke）上面建议使用非标准的HTTP标头（例如“ SEARCH”），这多是一个很好的解决方案，只是它受到支持的可能性更低。

列出能够执行以上全部操做的客户端可能会最有效率。

没法发送带有主体的GET的客户端（我知道）：

• XmlHTTPRequest提琴手

能够发送带有正文的GET的客户端：

• 大多数浏览器

能够从GET检索正文的服务器和库：

• 阿帕奇
• 的PHP

从GET剥离主体的服务器（和代理）：

• ？

---

#2楼

若是您确实想将可缓存的JSON / XML正文发送到Web应用程序，则放置数据的惟一合理位置是使用RFC4648编码的查询字符串：使用URL和Filename Safe Alphabet的Base 64编码 。 固然，您可使用urlencode JSON并将其放在URL参数的值中，可是Base64给出的结果较小。 请记住，存在URL大小限制，请参阅不一样浏览器中URL的最大长度是多少？ 。

您可能会认为Base64的padding =字符可能不利于URL的参数值，但事实并不是如此-请参阅如下讨论： http : //mail.python.org/pipermail/python-bugs-list/2007-February/037195.html 。 可是，您不该将没有参数名称的编码数据放进去，由于带有填充的编码字符串将被解释为具备空值的参数键。 我会使用相似?_b64=<encodeddata> 。

---

#3楼

恕我直言，您能够仅在URL发送通过JSON编码的（即encodeURIComponent ），这样您就不会违反HTTP规范并将JSON发送到服务器。

---

#4楼

restclient和REST控制台都不支持此功能，可是curl支持。

HTTP规范在第4.3节中说明

若是请求方法的规范（第5.1.1节）不容许在请求中发送实体，则消息体不得包含在请求中。

5.1.1节将各类方法重定向到9.x节。 它们都没有明确禁止包含消息正文。 然而...

5.2节说

经过检查Request-URI和Host标头字段来肯定Internet请求标识的确切资源。

9.3节说

GET方法意味着检索由Request-URI标识的任何信息（以实体形式）。

二者共同代表，在处理GET请求时， 不须要服务器检查Request-URI和Host标头字段之外的任何内容。

总而言之，HTTP规范并无阻止您使用GET发送消息正文，可是有足够的歧义，若是不是全部服务器都支持的话，它也不会令我感到惊讶。

---

#5楼

哪一个服务器会忽略它？ – fijiaaron 2012年8月30日在21:27

例如， 谷歌比忽略它作得更糟，它将认为这是一个错误 ！

使用简单的netcat本身尝试一下：

$ netcat www.google.com 80
GET / HTTP/1.1
Host: www.google.com
Content-length: 6

1234

（1234内容后跟CR-LF，所以总共为6个字节）

您将得到：

HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That’s an error.
Your client has issued a malformed or illegal request. That’s all we know.

您还会从Bing，Apple等处收到400错误请求，这些请求由AkamaiGhost提供。

所以，我不建议将GET请求与主体实体一块儿使用。