Do I need a content type for http get requests?

Question

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

1. The client sets a content type for the body he is sending to the server (e.g. for post)
2. The server sets a content type for the response.

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?

Answer 1

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

Answer 2

According to the RFC 7231 section 3.1.5.5:

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 "application/octet-stream" ([RFC2046], Section 4.5.1) or examine the data to determine its type.

It means that the Content-Type HTTP header should be set only for PUT and POST requests.

Answer 3

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.

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

Answer 4

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).

Answer 5

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