Content-Type標頭是否適用於除PUT或POST之外的任何HTTP謂詞？

Question

我正在嘗試使用CollectionSpace軟件的REST API，並注意到將其作為GET請求的一部分發送給Content-Type標頭會導致以下錯誤：

HTTP Status 415 - Cannot consume content type

我試過的兩個python REST客戶端庫，在谷歌代碼上的github和python-rest-client上的restclient，在發出GET請求時都會發送一個Content-Type頭。

我在審核http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html時的理解是，客戶端應該只在POST和PUT請求上發送Content-Type標頭。 那是對的嗎？

這兩個庫都發送了標頭的事實使我認為服務器通常會忽略它，而不是返回客戶端錯誤代碼。

Answer 1

雖然沒有在規范中明確概述，但可以做出一些推論。 第7.2.1節說明

包含實體主體的任何HTTP / 1.1消息應該包括定義該主體的媒體類型的Content-Type頭部字段。

這很明顯，而且很有意義。 鑒於此，我們可以查看第9節 （方法定義），看看哪些提到他們可能在請求體中有一個實體。 其中三個提到它：

OPTIONS

如果OPTIONS請求包含實體主體（由Content-Length或Transfer-Encoding的存在指示）......

POST

...用於請求原始服務器接受請求中包含的實體...

放

...請求將所包含的實體存儲在提供的Request-URI下

並且一種方法特別禁止實體， TRACE ：

TRACE請求不得包含實體。

實際上，您可以使用正文中的實體和Content-Type標頭發送任何方法（TRACE除外）。 但是，根據規范，我不希望服務器對它做任何事情，除非它是上面三種方法之一。

---

我還要說，您正在使用的響應HTTP狀態415的軟件違反了規范。

第4.3節說：

...如果請求方法不包含實體主體的定義語義，則在處理請求時應該忽略消息主體。

由於規范不包含具有GET請求的實體主體的已定義語義，因此服務器應忽略它。

另外，如果請求中沒有提供實體，並且Content-Length為零（假設Transfer-Encoding標頭未設置且不是“identity”），則服務器不應嘗試使用實體，無論請求如何方法或是否存在Content-Type標頭。 這可以通過確定第4.4節中描述的消息長度的優先順序來備份。

Answer 2

415無法使用內容類型

如果REST資源有@Consumes建議接受特定的MIME類型，則會出現此問題。 要修復此設置，請在Request / Resource調用中設置正確的“Accept”標頭以及“Content-Type”標頭。 對於來自RESTEasy的MockHttpRequest，它可以簡單地完成

request.accept（MediaType.APPLICATION_JSON）; request.contentType（MediaType.APPLICATION_JSON）;