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:
"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.