The problem with not passing over the content-type on a GET message is that sure the content-type is irrelevant because the server side determines the content anyway. The problem that I have encountered is that there are now a lot of places that set up their webservices to be smart enough to pick up the content-type that you pass and return the response in the 'type' that you request. Eg. we are currently messaging with a place that defaults to JSON, however, they have set their webservice up so that if you pass a content-type of xml they will then return xml rather than their JSON default. Which I think going forward is a great idea

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

rfc确切地表达了他们的意思。如果你方(客户端或源服务器)将发送额外的内容，除了HTTP报头，它应该指定一个内容类型报头。但是请注意，可以省略content - type而仍然包含内容(例如，通过使用content - length标头)。

Get请求不应该有内容类型，因为它们没有请求实体(即主体)。

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

不过它们是可选的。

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

The problem with not passing over the content-type on a GET message is that sure the content-type is irrelevant because the server side determines the content anyway. The problem that I have encountered is that there are now a lot of places that set up their webservices to be smart enough to pick up the content-type that you pass and return the response in the 'type' that you request. Eg. we are currently messaging with a place that defaults to JSON, however, they have set their webservice up so that if you pass a content-type of xml they will then return xml rather than their JSON default. Which I think going forward is a great idea

简短的回答:大多数情况下，您不需要HTTP GET请求的内容类型报头。但是规范似乎也没有排除HTTP GET的内容类型报头。

支撑材料:

"Content-Type" is part of the representation (i.e. payload) metadata. Quoted from RFC 7231 section 3.1: 3.1. Representation Metadata Representation header fields provide metadata about the representation. When a message includes a payload body, the representation header fields describe how to interpret the representation data enclosed in the payload body. ... The following header fields convey representation metadata: +-------------------+-----------------+ | Header Field Name | Defined in... | +-------------------+-----------------+ | Content-Type | Section 3.1.1.5 | | ... | ... | Quoted from RFC 7231 section 3.1.1.5(by the way, the current chosen answer had a typo in the section number): The "Content-Type" header field indicates the media type of the associated representation In that sense, a Content-Type header is not really about an HTTP GET request (or a POST or PUT request, for that matter). It is about the payload inside such a whatever request. So, if there will be no payload, there needs no Content-Type. In practice, some implementation went ahead and made that understandable assumption. Quoted from Adam's comment: "While ... the spec doesn't say you can't have Content-Type on a GET, .Net seems to enforce it in it's HttpClient. See this SO q&a." However, strictly speaking, the specs itself does not rule out the possibility of HTTP GET contains a payload. Quoted from RFC 7231 section 4.3.1: 4.3.1 GET ... A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request. So, if your HTTP GET happens to include a payload for whatever reason, a Content-Type header is probably reasonable, too.