据我所知,有两个地方可以设置内容类型:
这是否意味着我不必或不应该为所有的get请求(客户端)设置内容类型?如果我可以或者应该,那会是什么内容类型?
此外,我在一些帖子中读到,客户端的内容类型指定了客户端希望接收的内容类型。也许我的第一点是不对的?
Get请求不应该有内容类型,因为它们没有请求实体(即主体)。
GET请求可以有“Accept”报头,表示客户机可以理解哪些类型的内容。然后服务器可以使用它来决定发送回哪种内容类型。
不过它们是可选的。
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
根据RFC 7231章节3.1.5.5:
发送方,在该消息中生成包含有效载荷体应该生成一个Content-Type报头字段吗的消息,除非所附表示的预期媒体类型不为发送方所知。如果一个Content-Type报头字段不存在,接收者可以假设一个媒体类型为“application/octet-stream”;([RFC2046],章节4.5.1)或检查数据以确定其类型。
这意味着Content-Type HTTP头应该仅为PUT和POST请求设置。
Content-Type
PUT
POST
公认的答案是错误的。引用是正确的,PUT和POST必须拥有它的断言是不正确的。没有要求PUT或POST实际上有额外的内容。也没有禁止GET实际拥有内容。
rfc确切地表达了他们的意思。敌我识别你的一方(客户端或源服务器)将发送额外的内容,超出HTTP头,它应该指定一个内容类型头。但是请注意,可以省略content - type而仍然包含内容(例如,通过使用content - length标头)。
简单的回答:大多数情况下,你不需要是HTTP GET请求的内容类型报头。但是规范似乎也没有排除HTTP GET的内容类型报头。
支撑材料:
3.1. 表示元数据 表示报头字段提供关于 表示。当消息包含有效负载主体时, 表示报头字段描述如何解释 负载体中包含的表示数据. ... 以下报头字段传递表示元数据: +-------------------+-----------------+ | Header Field Name | Defined in... | +-------------------+-----------------+ | Content-Type | Section 3.1.1.5 | | ... | ... |
3.1. 表示元数据
表示报头字段提供关于 表示。当消息包含有效负载主体时, 表示报头字段描述如何解释 负载体中包含的表示数据. ...
以下报头字段传递表示元数据:
+-------------------+-----------------+ | Header Field Name | Defined in... | +-------------------+-----------------+ | Content-Type | Section 3.1.1.5 | | ... | ... |
引用自RFC 7231章节3.1.1.5(顺便说一下,当前选择的答案在节号中有一个错别字):
< p >“Content-Type"头字段表示对象的媒体类型 相关代表< / p >
“虽然……规范没有说你不能在GET上有Content-Type, . net似乎在它的HttpClient中强制了它。看到这个SO q&a !”
4.3.1得到 ... GET请求消息中的有效负载没有定义的语义; 在GET请求上发送有效负载主体可能会导致一些现有的问题
4.3.1得到
...
所以,如果你的HTTP GET因为某种原因碰巧包含了一个有效负载,Content-Type报头可能也是合理的。
我发现这篇文章在阐明“内容类型”概念方面非常有用,你可以查看它,在最后,有一个HTTP内容类型标头的常见值列表。
https://www.geeksforgeeks.org/http-headers-content-type/