HTTP Headers
Content Type
HTTP Header
The HTTP Content-Type representation header is used to specify the original media type of a resource before any content encoding is applied.
In responses, the Content-Type header informs the client about the media type of the returned data. In requests such as POST or PUT, the client uses the Content-Type header to specify the type of content being sent to the server. If a server implementation or configuration is strict about content type handling, a 415 client error response may be returned.
The Content-Type header differs from Content-Encoding in that Content-Encoding helps the recipient understand how to decode data to its original form.
* Values can’t contain a CORS-unsafe request header byte: "():<>?@[\]{},, delete 0x7F, and control characters 0x00 to 0x19 except for Tab 0x09. It also needs to have a media type of its parsed value (ignoring parameters) of either application/x-www-form-urlencoded, multipart/form-data, or text/plain.
Syntax
Content-Type: <media-type>
For example:
http
Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=ExampleBoundaryString
Directives
<media-type>
The media type specifies the type of resource or data. It may include the following parameters:
charset: Indicates the character encoding standard used. The value is case insensitive, but using lowercase is recommended.
boundary: Necessary for multipart entities. It separates different parts of a message. The boundary value typically consists of 1 to 70 characters, not ending with whitespace, and should be robust across systems such as email gateways. Usually, in the message, the boundary is preceded by two dashes, and the final boundary ends with two dashes as well.
Example
Serving assets with the correct content type is essential for proper handling and performance. When JavaScript and CSS assets are served using text/javascript and text/css respectively, browsers can process them securely and efficiently. Proper configuration of server MIME types ensures assets are interpreted correctly, enhancing security and performance.
http
HTTP/1.1 200
content-encoding: br
content-type: text/javascript; charset=utf-8
vary: Accept-Encoding
date: Fri, 21 Jun 2024 14:02:25 GMT
content-length: 2978
const videoPlayer=document.getElementById...
http
HTTP/3 200
server: nginx
date: Wed, 24 Jul 2024 16:53:02 GMT
content-type: text/css
vary: Accept-Encoding
content-encoding: br
.super-container{clear:both;max-width:100%}...
Content-Type in multipart forms
In a POST request resulting from an HTML form submission, the Content-Type of the request is specified by the enctype attribute on the form element.
html
<form action="/foo" method="post" enctype="multipart/form-data">
<input type="text" name="description" value="Description input value" />
<input type="file" name="myFile" />
<button type="submit">Submit</button>
</form>
The request typically looks like the following, with some headers omitted for brevity. A boundary string is used to separate parts of the form data, which is generated dynamically by the browser (e.g., ---------------------------1003363413119651595289485765 in this example).
http
POST /foo HTTP/1.1
Content-Length: 68137
Content-Type: multipart/form-data; boundary=ExampleBoundaryString
--ExampleBoundaryString
Content-Disposition: form-data; name="description"
Description input value
--ExampleBoundaryString
Content-Disposition: form-data; name="myFile"; filename="foo.txt"
Content-Type: text/plain
[content of the file foo.txt chosen by the user]
--ExampleBoundaryString--
Content-Type in URL-encoded form submission
When forms do not involve file uploads and use simple fields, URL-encoded forms are more straightforward, with data included in the request body as URL-encoded key-value pairs.
html
<form action="/submit" method="post">
<label for="comment">Comment:</label>
<input type="text" id="comment" name="comment" value="Hello!" />
<button type="submit">Submit</button>
</form>
http
POST /submit HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
comment=Hello!
Content-Type in a REST API using JSON
Many REST APIs utilize application/json as the content type, which is ideal for machine-to-machine communication or programmatic interactions. A typical successful response includes a 201 Created status and a JSON payload representing the created resource.
http
HTTP/1.1 201 Created
Content-Type: application/json
{
"message": "New user created",
"user": {
"id": 123,
"firstName": "Paul",
"lastName": "Klee",
"email": "[email protected]"
}
}
How to Modify Header using Requestly
Requestly is a powerful Chrome extension that allows you to modify HTTP headers, including the Content-Type header. This is especially useful for testing how your server handles different types of data or for debugging issues related to content handling. Steps to Modify the Content-Type Header:
- Install and open the Requestly Chrome extension. You can find it on the Chrome Web Store.
- Create a new rule: Click on “Create Rule” and choose “Modify Headers” from the list of available rule types.
- Add a new header modification:
- Under “Action”, select “Add” or “Override”.
- In the “Header Name” field, enter Content-Type.
- In the “Header Value” field, enter your preferred content type (e.g., application/json).
- Set the URL condition: Specify the URL or pattern where this header change should apply (e.g., https://your-api.com/*).
- Save the rule.
Once configured, Requestly will modify the Content-Type header for all matching requests, enabling you to test how your backend processes different types of payloads or troubleshoot content format issues. You might need to modify the Content-Type header to make sure your server correctly understands the format of the incoming data. This helps in debugging or testing different content formats like JSON, XML, or form data without changing your client code.
Table of Contents
- No headings found.
