Understanding the Http Content-Type header

One apparently simple part of your request that can make a big difference.
By Gabriel Nepomuceno Posted 16 December 2015

Understanding the Http Content-Type header

One part of the request that is often overlooked is the Content-Type header. I stumbled over a question today on StackOverflow that made me realized how this simple aspect can be so confusing.

The Content-Type header it is quite simple, you use it to specify the type of content that you are sending and the type of content you want to receive, it is split in 3 different parts.

Type / Subtype ; Parameters

Type

Type is the top group of the Content-Type header. Some of the most common values for type are text, application and video.

Subtype

This part is also well known because it is a mandatory field that people normally use to identify what kind of data they are sending. Some examples of this combinations could be:

  • text/json
  • text/plain
  • image/jpeg
  • application/atom+xml

An extensive list of formatters can be found here, including their mime types and sources.

Parameters

This is the part that most people forget when they are dealing with content types and was the source of the error on the question that inspire this post.

For now, we will be focusing on the charset but the parameters can be used to define more things than that, such as when you are sending video or audio content.

The default charset according to W3C is US-ASCII so if you are sending non ascii, or unicode chars it is safer to use a different charset.

This makes it possible to send Japanese chars like インターネット (internet in Japanese, according to google translator) without corrupting the payload.

An example Content-Type of a request using a charset could be:

application/x-www-form-urlencoded;charset=utf-8

Thank you all!

Gabriel Nepomuceno
Gabriel Nepomuceno
Subjects Expert