我正在尝试使用CollectionSpace软件的REST API，并注意到在GET请求中发送Content-Type标头会导致以下错误：
HTTP Status 415 - Cannot consume content type
我尝试过的两个python REST客户端库，在Google代码上的github和python-rest-client上都是restclient，在发出GET请求时会发送一个Content-Type标头。
我对审核http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html的理解是，客户端应该只在POST和PUT请求上发送Content-Type标头。那是对的吗？
这两个库都发送了标头这一事实使我认为服务器通常忽略它，而不是返回客户端错误代码。
答案 0 :(得分：5)
虽然规范中没有明确概述，但可以做出一些推论。 Section 7.2.1个州
包含的任何HTTP / 1.1消息 实体 - 身体应该包括一个 Content-Type标题字段定义 该机构的媒体类型。
这很明显，而且很有道理。鉴于此，我们可以查看Section 9（方法定义），看看哪些提到他们可能在请求体中有一个实体。其中三人提到了它：
如果OPTIONS请求包含 实体 - 身体（如 内容长度或 传输编码）...
...用于请求原产地 服务器接受所包含的实体 请求......
...请求附上的实体 存放在提供的 请求URI
一种方法特别禁止实体， TRACE ：
TRACE请求不得包含 实体。
实际上，您可以使用正文中的实体和Content-Type标头发送任何方法（TRACE除外）。但是，根据规范，我不希望服务器对它做任何事情，除非它是上述三种方法之一。
我还要说，您使用的响应HTTP状态415的软件违反了规范。
...如果请求方法没有 包括为...定义的语义 entity-body，然后是message-body 处理时应该忽略 请求。
由于规范不包含具有GET请求的实体主体的已定义语义，因此服务器应忽略它。
此外，如果请求中未提供实体，并且Content-Length为零（假设Transfer-Encoding标头未设置且不是“identity”），则服务器不应尝试使用实体，无论请求方法或是否存在Content-Type标头。这可以通过优先顺序来备份，以确定Section 4.4中描述的消息长度。
答案 1 :(得分：2)
415无法使用内容类型
如果REST资源的@Consumes建议接受特定的MIME类型，则会出现此问题。要修复此设置，请在Request / Resource调用中设置正确的“Accept”标头以及“Content-Type”标头。对于来自RESTEasy的MockHttpRequest，它可以简单地完成
request.accept（MediaType.APPLICATION_JSON）; request.contentType（MediaType.APPLICATION_JSON）;