我是否需要 HTTP GET 请求的内容类型标头？答案

【问题标题】：Do I need a content-type header for HTTP GET requests?我是否需要 HTTP GET 请求的内容类型标头？
【发布时间】：2011-08-05 10:02:27
【问题描述】：

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

客户端为其发送到服务器的正文设置内容类型（例如，用于发布）
服务器为响应设置内容类型。

这是否意味着我不必或不应该为我的所有获取请求（客户端）设置内容类型。如果我可以或应该是什么内容类型？

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

【问题讨论】：

标签： http get content-type

【解决方案1】：

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

辅助材料：

“Content-Type”是表示（即有效负载）元数据的一部分。引自 RFC 7231 section 3.1:
3.1。表示元数据

表示头字段提供有关表示。当消息包含有效负载正文时，表示头字段描述如何解释包含在有效负载主体中的表示数据。 ...

以下标头字段传达表示元数据：
```
+-------------------+-----------------+
| 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 请求，就此而言）无关。它是关于这样一个 whatever 请求中的有效负载。所以，如果没有有效载荷，就不需要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 标头也可能是合理的。

【讨论】：

【解决方案2】：

在 GET 消息中不传递内容类型的问题在于，确保内容类型无关紧要，因为服务器端无论如何都会确定内容。我遇到的问题是，现在有很多地方将其 Web 服务设置为足够智能，以获取您传递的内容类型并以您请求的“类型”返回响应。例如。我们目前正在与默认为 JSON 的地方进行消息传递，但是，他们已经设置了他们的 web 服务，因此如果您传递 xml 的内容类型，他们将返回 xml 而不是他们的默认 JSON。我认为这是一个好主意

【讨论】：

【解决方案3】：

根据RFC 7231 section 3.1.5.5：

生成包含有效负载正文的消息的发送者应该在该消息中生成 Content-Type 标头字段，除非发送者不知道封闭表示的预期媒体类型。如果没有 Content-Type 标头字段，接收者可以假设媒体类型为“application/octet-stream” ([RFC2046], Section 4.5.1) 或检查数据以确定其类型。 p>

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

【讨论】：

@Epoc，引用的消息充其量是隐含的。 实际上并没有说没有 entity-body SHOULD NOT 的消息包含 Content-Type。我们有明确的报价吗？
@Pacerier 请不要删除别人答案的核心结论，即使它是错误的。我同意 Epoc 的回答是错误的 - 他引用的部分中没有任何内容支持他的回答的结论，它应该被否决。但这并不意味着您应该编辑答案以消除其核心前提，从而完全改变其含义。
我认为你们在阅读@Epoc 的话太字面意思了。当然，引用的部分并不意思他所说的意思。但我认为这个结论在 OPs 问题的背景下是正确的。 OP 正在寻求明确何时包含 Content-Type 以及何时不包含。 Epoc 提供了有关如何使用标头的信息，并得出结论任何合理的开发人员都会：您“应该”对具有有效负载主体（主要是 PUT 和 POST）的请求使用内容类型，并且您可能“不应该”使用它在没有用的地方，比如 GET 或 HEAD 等。
你的帖子声明，“这意味着......” - 是一个延伸。
@Pacerier 它实际上并不需要，但是它确实说“GET 请求消息中的有效负载没有定义的语义；在 GET 请求上发送有效负载主体可能会导致一些现有的拒绝请求的实施。” - 我仍然将其解释为“不应该”（最佳实践）而不是明确的“不得”，这只是表明您不应该期望跨服务器实现的一致性。但是是的，如果你确实包含了一个有效载荷，你“应该”也包含Content-Type；它只是GET 中的一个有效负载，不是标准的一部分。

【解决方案4】：

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

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

【讨论】：

【解决方案5】：

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

但它们是可选的。

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

【讨论】：

【解决方案6】：

Get 请求不应具有 content-type，因为它们没有请求实体（即正文）

【讨论】：

@Dmitry，需要引用，否则它是假设，而不是事实。
虽然我同意规范没有说你不能在 GET 上使用 Content-Type，但 .Net 似乎在它的 HttpClient 中强制执行它。见stackoverflow.com/questions/10679214/…
规范甚至没有强制 GET 请求没有正文......
我同意“不应该”，因为行为没有定义（根据规范），仅此而已。同样，“应该”与“不得”不同。只是不要期望一致的行为，因为再次按照规范：“GET 请求消息中的有效负载没有定义的语义；在 GET 请求上发送有效负载主体可能会导致某些现有实现拒绝请求。”但是，如果你要这样做，那么Content-Type 肯定会有意义。