blocks|key|3187727|text|Get请求不应该具有content-type，因为它们没有请求实体(即body)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3187728|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Get requests should not have content-type because they do not have request entity (that is, a body)

blocks|key|273975|text|GET请求可以有"Accept“头，表明客户端理解哪些类型的内容。然后，服务器可以使用它来决定发送回哪种内容类型。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|273976|不过，它们是可选的。|273977|http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1|offset|length|273978|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|1Q|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@$F|R|G|S|1|T]]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|E]]]]

GET requests can have "Accept" headers, which say which types of content the client understands. The server can then use that to decide which content type to send back.

They're optional though.

<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1" rel="noreferrer">http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1</a>

blocks|key|270345|text|根据RFC+7231+section+3.1.5.5的说法|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|270346|270347|生成包含有效负载正文的消息的发送方应在该消息中生成内容类型报头字段，除非所附表示的预期媒体类型对发送方未知。如果不存在内容类型报头字段，则接收方可以假定媒体类型为“/octet-stream”([RFC2046],+Section+4.5.1)，或者检查数据以确定其类型。|blockquote|style|BOLD|270348|270349|270350|这意味着应该只为PUT和POST请求设置Content-Type+header。|CODE|270351|entityMap|0|LINK|mutability|MUTABLE|url|https://www.rfc-editor.org/rfc/rfc7231#section-3.1.1.5|1|https://www.rfc-editor.org/rfc/rfc2046#section-4.5.1^0|2|O|0|0|0|A|N|1I|S|2P|O|1|0|0|0|8|3|C|4|K|C|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]]|C|$]]|$1|D|3|-4|5|6|7|12|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|13|8|@$A|14|B|15|H|I]|$A|16|B|17|H|I]]|9|@$A|18|B|19|1|1A]]|C|$]]|$1|J|3|-4|5|6|7|1B|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|1C|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|1D|8|@$A|1E|B|1F|H|N]|$A|1G|B|1H|H|N]|$A|1I|B|1J|H|N]]|9|@]|C|$]]|$1|O|3|-4|5|6|7|1K|8|@]|9|@]|C|$]]]|P|$Q|$5|R|S|T|C|$U|V]]|W|$5|R|S|T|C|$U|X]]]]

According to the <a href="https://www.rfc-editor.org/rfc/rfc7231#section-3.1.1.5" rel="noreferrer">RFC 7231 section 3.1.5.5</a>:
<blockquote>
A sender that generates a message containing a payload body SHOULD generate a Content-Type header field in that message unless the intended media type of the enclosed representation is unknown to the sender. If a Content-Type header field is not present, the recipient MAY either assume a media type of &quot;application/octet-stream&quot; (<a href="https://www.rfc-editor.org/rfc/rfc2046#section-4.5.1" rel="noreferrer">[RFC2046], Section 4.5.1</a>) or examine the data to determine its type.
</blockquote>
It means that the <code>Content-Type</code> HTTP header should be set only for <code>PUT</code> and <code>POST</code> requests.

blocks|key|3187792|text|公认的答案是错误的。引用是正确的，PUT和POST必须包含它的断言是不正确的。没有要求PUT或POST实际上有额外的内容。也没有禁止GET实际拥有内容的规定。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3187793|RFC确切地说出了他们的意思..如果HTTP端(客户端或源站)要发送除报头之外的其他内容，则应指定content+-报头。但请注意，允许省略Content-Type而仍然包含内容(例如，通过使用Content-Length头部)。|offset|length|style|BOLD|3187794|entityMap^0|0|Z|N|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

The accepted answer is wrong. The quote is correct, the assertion that PUT and POST must have it is incorrect. There is no requirement that PUT or POST actually have additional content. Nor is there a prohibition against GET actually having content.

The RFCs say exactly what they mean .. IFF your side (client OR origin server) will be sending additional content, beyond the HTTP headers, it SHOULD specify a Content-Type header. But note it is allowable to omit the Content-Type and still include content (say, by using a Content-Length header).

blocks|key|3187816|text|在GET消息中不传递content-type的问题在于，确保content-type是无关紧要的，因为服务器端无论如何都会决定内容。我遇到的问题是，现在有很多地方将他们的set服务设置得足够智能，可以拾取您传递的内容类型，并在您请求的'type‘中返回响应。例如：我们目前正在与一个默认为JSON的地方进行消息传递，然而，他们已经设置了他们的we服务，以便如果您传递一个内容类型的xml，他们将返回xml而不是他们的JSON默认值。我认为这是一个很好的想法|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3187817|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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

blocks|key|275990|text|简短回答:很可能不，您不需要为HTTP+GET请求一个内容类型的头。但是规范似乎也没有排除HTTP+GET的内容类型标头。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|275991|支持材料：|275992|275993|"Content-Type“是表示(即有效负载)元数据的一部分。引用自RFC+7231+section+3.1：|ordered-list-item|offset|length|275994|275995|3.1。表示元数据|275996|表示头字段提供关于表示的元数据。当消息包括有效载荷正文时，表示头字段描述如何解释包含在有效载荷正文中的表示数据。..。|275997|以下报头字段表示表示元数据：|275998|%2B-%2B%7C表头字段名%7C定义于...%2B-%2B%7C内容类型%7C第3.1.1.5节%7C%7C+...+%7C+...+%7C|275999|引用自RFC+7231+section+3.1.1.5(顺便说一句，当前选择的答案在章节编号中有一个拼写错误)：|276000|Content-+type报头字段指示相关表示的媒体类型|276001|276002|从这个意义上讲，Content-Type头实际上并不是关于HTTP+GET请求(或者POST或PUT请求)。它是关于这样一个请求中的有效负载。因此，如果没有有效负载，就不需要Content-Type。在实践中，一些实现继续进行，并做出了可以理解的假设。引用自Adam's+comment：|style|CODE|276003|276004|“虽然...规范并没有说GET不能有Content-Type，但.Net似乎在它的HttpClient中强制执行了这一点。请参阅this+SO+q&a."|276005|276006|然而，严格地说，规范本身并不排除HTTP+GET包含有效负载的可能性。引用自RFC+7231+section+4.3.1：|276007|276008|4.3.1获取|276009|..。|276010|GET请求消息中的有效负载没有定义的语义；在GET请求上发送有效负载正文可能会导致某些现有实现拒绝该请求。|276011|因此，如果您的HTTP+GET由于某种原因恰好包含了一个有效负载，那么Content-Type报头可能也是合理的。|276012|entityMap|0|LINK|mutability|MUTABLE|url|https://www.rfc-editor.org/rfc/rfc7231#section-3.1|1|https://www.rfc-editor.org/rfc/rfc7231#section-3.1.1.5|2|https://stackoverflow.com/questions/5661596/do-i-need-a-content-type-header-for-http-get-requests#comment84164786_5661614|3|https://stackoverflow.com/questions/10679214/how-do-you-set-the-content-type-header-for-an-httpclient-request|4|https://www.rfc-editor.org/rfc/rfc7231#section-4.3.1^0|0|0|0|Z|K|0|0|0|0|0|0|0|3|O|1|0|0|0|8|C|2F|C|3L|E|2|0|0|1S|B|3|0|0|12|M|4|0|0|0|0|0|Z|C|0^^$0|@$1|2|3|4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1X|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|1Z|8|@]|9|@$H|20|I|21|1|22]]|A|$]]|$1|J|3|-4|5|6|7|23|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|24|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|25|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|26|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|27|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|28|8|@]|9|@$H|29|I|2A|1|2B]]|A|$]]|$1|U|3|V|5|6|7|2C|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|2D|8|@]|9|@]|A|$]]|$1|X|3|Y|5|G|7|2E|8|@$H|2F|I|2G|Z|10]|$H|2H|I|2I|Z|10]]|9|@$H|2J|I|2K|1|2L]]|A|$]]|$1|11|3|-4|5|6|7|2M|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|2N|8|@]|9|@$H|2O|I|2P|1|2Q]]|A|$]]|$1|14|3|-4|5|6|7|2R|8|@]|9|@]|A|$]]|$1|15|3|16|5|G|7|2S|8|@]|9|@$H|2T|I|2U|1|2V]]|A|$]]|$1|17|3|-4|5|6|7|2W|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|2X|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|2Y|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|2Z|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|30|8|@$H|31|I|32|Z|10]]|9|@]|A|$]]|$1|1G|3|-4|5|6|7|33|8|@]|9|@]|A|$]]]|1H|$1I|$5|1J|1K|1L|A|$1M|1N]]|1O|$5|1J|1K|1L|A|$1M|1P]]|1Q|$5|1J|1K|1L|A|$1M|1R]]|1S|$5|1J|1K|1L|A|$1M|1T]]|1U|$5|1J|1K|1L|A|$1M|1V]]]]

Short answer: Most likely, no you do not need a content-type header for HTTP GET requests. But the specs does not seem to rule out a content-type header for HTTP GET, either.
Supporting materials:
<ol>
<li>&quot;Content-Type&quot; is part of the representation (i.e. payload) metadata. Quoted from
<a href="https://www.rfc-editor.org/rfc/rfc7231#section-3.1" rel="nofollow noreferrer">RFC 7231 section 3.1</a>:
<blockquote>
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:
<pre><code>+-------------------+-----------------+
| Header Field Name | Defined in... |
+-------------------+-----------------+
| Content-Type | Section 3.1.1.5 |
| ... | ... |
</code></pre>
</blockquote>
Quoted from <a href="https://www.rfc-editor.org/rfc/rfc7231#section-3.1.1.5" rel="nofollow noreferrer">RFC 7231 section 3.1.1.5</a>(by the way, the current chosen answer had a typo in the section number):
<blockquote>
The &quot;Content-Type&quot; header field indicates the media type of the
associated representation
</blockquote>
</li>
<li>In that sense, a <code>Content-Type</code> 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 <code>Content-Type</code>. In practice, some implementation went ahead and made that understandable assumption. Quoted from <a href="https://stackoverflow.com/questions/5661596/do-i-need-a-content-type-header-for-http-get-requests#comment84164786_5661614">Adam's comment</a>:
<blockquote>
&quot;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 <a href="https://stackoverflow.com/questions/10679214/how-do-you-set-the-content-type-header-for-an-httpclient-request">this SO q&amp;a</a>.&quot;
</blockquote>
</li>
<li>However, strictly speaking, the specs itself does not rule out the possibility of HTTP GET contains a payload. Quoted from <a href="https://www.rfc-editor.org/rfc/rfc7231#section-4.3.1" rel="nofollow noreferrer">RFC 7231 section 4.3.1</a>:
<blockquote>
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.
</blockquote>
So, if your HTTP GET happens to include a payload for whatever reason, a <code>Content-Type</code> header is probably reasonable, too.
</li>
</ol>

As far as I understood there are two places where to set the content type:

<ol>
<li>The client sets a content type for the body he is sending to the server (e.g. for post)</li>
<li>The server sets a content type for the response.</li>
</ol>

Does this mean I don't have to or should not set a content type for all my get requests (client side). And if I can or should what content type would that be?

Also I read in a few posts that the content type of the client specifies what type of content the client would like to receive. So maybe my point 1 is not right?

Do I need a content-type header for HTTP GET requests?

服务器

JSON

据我所知，有两个地方可以设置内容类型：客户端为他发送到服务器的正文设置内容类型(例如，用于post)服务器设置响应的内容类型。这是否意味着我不必或不应该为所有的get请求设置内容类型(客户端)。如果我可以或者应该是什么内容类型呢？另外，我在一些帖子中看到，客户端的内容类型指定了客户端希望接收的内容类型。因此，也许我的观...

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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