Question

据我所知，有两个地方可以设置内容类型：

客户端为他发送给服务器的主体设置内容类型（例如发布）
服务器为响应设置内容类型。

这是否意味着我不必或不应该为我的所有get请求（客户端）设置内容类型。如果我能够或应该采用什么内容类型？

我还在一些帖子中读到，客户端的内容类型指定了客户端希望接收的内容类型。也许我的观点1不对？

Answer 1

生成包含有效负载正文的消息的发件人应该在该消息中生成Content-Type标头字段，除非发件人不知道所包含的表示的预期媒体类型。如果，Content-Type标头字段不存在，则收件人可以采用媒体类型“application / octet-stream”（[RFC2046], Section 4.5.1）或检查数据以确定其类型。

这意味着只应为Content-Type和PUT请求设置POST HTTP标头。

Answer 2

获取请求不应具有内容类型，因为它们没有请求实体（即正文）

Answer 3

GET请求可以有“Accept”标头，表示客户端理解的内容类型。然后，服务器可以使用它来决定要发回的内容类型。

他们是可选的。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1

Answer 4

接受的答案是错误的。引用是正确的，PUT和POST必须拥有它的断言是不正确的。不要求PUT或POST实际上有其他内容。也没有禁止GET实际拥有内容。

RFC确切地说出它们的意思.. IFF 您的身边（客户端或原始服务器）将发送额外的内容，除了HTTP标头之外，它应该指定Content-Type标头。但请注意，允许省略Content-Type并仍然包含内容（例如，使用Content-Length标头）。

Answer 5

简短的回答：很可能，不是您不需要 HTTP GET请求的内容类型标头。但是规范似乎也不排除HTTP GET的内容类型标头。

辅助材料：

“内容类型”是表示（即有效负载）元数据的一部分。引用自 RFC 7231 section 3.1：
3.1。表示元数据

Representation标头字段提供有关表示。当邮件包含有效内容主体时，制图表达标题字段描述了如何解释有效载荷主体中包含的表示形式数据。 ...

以下标头字段传达表示形式元数据：
```
+-------------------+-----------------+
| Header Field Name | Defined in...   |
+-------------------+-----------------+
| Content-Type      | Section 3.1.1.5 |
| ...               | ...             |
```
引自RFC 7231 section 3.1.1.5（顺便说一下，当前选择的答案的章节编号有错字）：

“ Content-Type”标头字段指示相关的表示形式
从这个意义上说，Content-Type头实际上与HTTP GET请求（或POST或PUT请求）无关。关于这样的 every 请求中的有效负载。因此，如果没有有效载荷，则不需要Content-Type。在实践中，进行了一些实现并做出了可以理解的假设。引自Adam's comment：

“虽然...规范没有说您不能在GET上使用Content-Type，但.Net似乎在它的HttpClient中强制执行它。请参阅this SO q&a。”
但是，严格来说，规范本身并不排除HTTP GET包含有效负载的可能性。引自RFC 7231 section 4.3.1：

4.3.1获取

...

GET请求消息中的有效载荷没有定义的语义；在GET请求上发送有效内容正文可能会导致一些现有内容拒绝请求的实现。

因此，如果您的HTTP GET出于某种原因恰好包含有效负载，那么Content-Type标头也可能是合理的。

Answer 6

不传递GET消息上的内容类型的问题是，确保内容类型无关紧要，因为服务器端还是要确定内容。我遇到的问题是，现在有很多地方将其Web服务设置为足够聪明，以选择您传递的内容类型并以您请求的“类型”返回响应。例如。我们当前正在使用默认为JSON的位置进行消息传递，但是，他们已经设置了Web服务，因此，如果您传递xml的内容类型，则它们将返回xml而不是其JSON默认值。我认为前进是一个好主意

我是否需要http get请求的内容类型？

6 个答案: