帶請求正文的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請求與主體實體一塊兒使用。