What is a Content Type?
Content types also known as MIME type or media types are a two part identifier for file formats. The HTTP header Content-Type is responsible for telling the HTTP client or server what type of data is being sent.
Headers
Two main headers are involved when it comes to content types
- Accept — When a HTTP client requests data from a server it can send a comma separated list of media types. For example the headers value could be text/html, text/plain. This hints to the server what the client is looking for. Basically the client is asking the server to respond with text/html and if it cannot handle that try responding with text/plain. Whether or not the server can handle or will honor this is up to the server.
- Content-Type — The content type header tells the client or server what format the data is being transferred in. If the client asked for text/html and the server handled it properly the data should come back with the Content-Type: text/html header. This header is how your browser knows when to render the html vs just displaying raw text. This is also used for images / files.
$ curl -v http://www.google.com * Rebuilt URL to: http://www.google.com/ * Trying 172.217.1.68. * Connected to www.google.com (172.217.1.68) port 80 (#0) > GET / HTTP/1.1 > Host: www.google.com > User-Agent: curl/7.49.1 > Accept: */* > < HTTP/1.1 200 OK < Date: Tue, 10 Jan 2017 02:42:41 GMT < Expires: -1 < Cache-Control: private, max-age=0 < Content-Type: text/html; charset=ISO-8859-1
Notice the Accept: */*, This means accept any format. The Content-Type: text/html header tells the client the server responded with HTML.
Media Types
- text/plain - Simple Raw text
- text/html - Standard HTML, when a browser gets this media type it knows to render the page as HTML instead of raw text. This includes fetching external files such as javascript, css, and images.
- application/octet-stream - A binary file format often used to download files. If a browser gets this media type it automatically downloads the file instead of trying to display / render it.
- application/json - The JSON data format.
- application/pdf - PDF file.
- image/[png,jpeg,gif] - Standard image formats.
These are only some of the formats. As you can see the difference between rendering html vs showing raw text vs downloading a file is all controlled with a simple header. Handling content types with Undertow
Difference between HTML Document Type and Content type?
The HTTP Content-Type header, for which the http-equiv="Content-Type" HTML meta tag is a fallback only, signifies what general type of document the document is. Is it a text/html document and should the browser fire up its HTML parser? Or is it an application/pdf document and the browser needs to load its PDF plugin? Or is it something completely different? This header/tag should also specify the encoding the document is in, if applicable.
The HTML Document Type specifies the exact type and version of the HTML document. Is it an HTML 5 document? HTML 4 Strict? Transitional? Or just legacy tag soup?
The document type declaration is there mainly for
- DTD (document type definition)-based validation
- triggering different browser rendering modes
The HTML5 doctype declaration is solely there for triggering standards mode in browsers, since HTML5 has no document type definition.
The content type is what determines whether a page is served as HTML markup or XML-serialized (XHTML) markup.
For HTML, it is text/html . This is the default for most Web pages.
For XHTML, it is (usually) application/xhtml+xml . There's also a character encoding, typically charset=utf-8 . This usually doesn't matter, though; in most cases the content type will be sent in the Content-Type HTTP header by the server. When a browser picks up the header it will ignore the meta tag. In HTML5 only the charset is specified:
What are all the possible values for HTTP "Content-Type" header?
I have to validate the Content-Type header value before passing it to an HTTP request. Is there a specific list for all the possible values of Content-Type ? Otherwise, is there a way to validate the content type before using it in an HTTP request?
Valid media types are supposed to be registered with the IANA - you can see a current list here: iana.org/assignments/media-types/media-types.xhtml but note this list can update over time. There is not a fixed allowed list.
@Joe: "Valid media types are supposed to be registered with the IANA" - wait, does this mean custom media types (only for use in an application-specific web API that is only going to be called by a custom client application) are not permitted at all?
@O.R.Mapper i'd read it more as "there is an official list, but i would not be surprised to see lots of others in the wild". In terms of the OP's question, if you were going to try and validate "all types" you'd at least want to validate all registered types. What to do with additional ones is more open-ended. As far as I know there is no requirement to register custom types.
Please accept the answer which helped you most in solving your problem. It helps future readers. If the answers weren't helpful leave comments below them. So the poster can update them accordingly. Read What should I do when someone answers my question? to know more.
4 Answers 4
The most common types are:
application/java-archive application/EDI-X12 application/EDIFACT application/javascript application/octet-stream application/ogg application/pdf application/xhtml+xml application/x-shockwave-flash application/json application/ld+json application/xml application/zip application/x-www-form-urlencoded
audio/mpeg audio/x-ms-wma audio/vnd.rn-realaudio audio/x-wav
image/gif image/jpeg image/png image/tiff image/vnd.microsoft.icon image/x-icon image/vnd.djvu image/svg+xml
multipart/mixed multipart/alternative multipart/related (using by MHTML (HTML mail).) multipart/form-data
text/css text/csv text/html text/javascript (obsolete) text/plain text/xml
video/mpeg video/mp4 video/quicktime video/x-ms-wmv video/x-msvideo video/x-flv video/webm
application/vnd.android.package-archive application/vnd.oasis.opendocument.text application/vnd.oasis.opendocument.spreadsheet application/vnd.oasis.opendocument.presentation application/vnd.oasis.opendocument.graphics application/vnd.ms-excel application/vnd.openxmlformats-officedocument.spreadsheetml.sheet application/vnd.ms-powerpoint application/vnd.openxmlformats-officedocument.presentationml.presentation application/msword application/vnd.openxmlformats-officedocument.wordprocessingml.document application/vnd.mozilla.xul+xml
In the Extended BNF notation of RFC 822, a Content-Type header field value is defined as follows:
Content-Type := type "/" subtype *[";" parameter]
type := "application" / "audio" / "image" / "message" / "multipart" / "text" / "video" / x-token
x-token :=
subtype := token
parameter := attribute "=" value
attribute := token
value := token / quoted-string
token := 1*
tspecials := "(" / ")" / "" / "@" ; Must be in / "," / ";" / ":" / "" / ; quoted-string, / "/" / "[" / "]" / "?" / "." ; to use within / "=" ; parameter values
And a list of known MIME types that can follow it (or, as Joe remarks, the IANA source).
As you can see the list is way too big for you to validate against all of them. What you can do is validate against the general format and the type attribute to make sure that is correct (the set of options is small) and just assume that what follows it is correct (and of course catch any exceptions you might encounter when you put it to actual use).
Also note the comment above:
If another primary type is to be used for any reason, it must be given a name starting with "X-" to indicate its non-standard status and to avoid any potential conflict with a future official name.
You'll notice that a lot of HTTP requests/responses include an X- header of some sort which are self defined, keep this in mind when validating the types.