Most Common HTTP Response Header with Examples

Introduction

HTTP response headers provide additional information about the server’s response to an HTTP request. These headers are essential for web developers and server administrators to ensure efficient and secure communication between clients and servers. In this blog post, we will discuss some of the most common HTTP response headers and provide example values for each header.

Response Headers

Content-Type

This header specifies the MIME type of the content being sent in the response. The MIME type tells the browser or other client how to interpret the content. For example, if the Content-Type is set to “text/html”, the browser knows to display the response as an HTML document. Other common MIME types include “application/json” for JSON data and “image/png” for PNG images.

Example 1: Content-Type: text/html
Example 2: Content-Type: application/json
Example 3: Content-Type: image/png

Cache-Control

This header specifies how the response should be cached. The value can include directives such as “public” to allow caching by any client, “private” to limit caching to the browser or other client, “no-cache” to indicate that the response should not be cached, and “max-age” to specify how long the response can be cached.

Example 1: Cache-Control: max-age=3600, public
Example 2: Cache-Control: no-cache
Example 3: Cache-Control: must-revalidate

Location

This header is used to redirect the client to a different URL. The client should automatically follow the URL in the Location header. This is commonly used for HTTP redirects, such as when a user submits a form and is redirected to a confirmation page.

Example 1: Location: https://www.example.com/newpage
Example 2: Location: /error.html
Example 3: Location: https://www.example.com/redirected

This header is used to set a cookie in the client’s browser. Cookies are small pieces of data that can be used to store information about the user or their session. The Set-Cookie header can include a name, value, expiration date, and other parameters.

Example 1: Set-Cookie: sessionId=12345; Expires=Thu, 01 Jan 2024 00:00:00 GMT
Example 2: Set-Cookie: userId=67890; Secure; HttpOnly
Example 3: Set-Cookie: preference=darkmode; Domain=example.com

Server

This header identifies the web server software being used to serve the response. The value of the header typically includes the name and version of the server software.

Example 1: Server: Apache/2.4.41 (Unix)
Example 2: Server: Microsoft-IIS/10.0
Example 3: Server: nginx/1.21.0

Expires

This header specifies the date and time after which the response should be considered stale. If a client requests the same resource before the expiration date has passed, the server can return a cached copy of the resource.

Example 1: Expires: Sat, 08 May 2023 12:00:00 GMT
Example 2: Expires: 0
Example 3: Expires: Thu, 01 Jan 1970 00:00:00 GMT

Content-Length

This header specifies the length of the content being sent in the response. This can be useful for the client to know how much data to expect and for the server to know how much data to send. When you are downloading a file from internet, the broweser looks at this header to determine how big the file is.

Example 1: Content-Length: 1024
Example 2: Content-Length: 2048
Example 3: Content-Length: 4096

Last-Modified

This header specifies the date and time when the content being sent in the response was last modified. This can be used by clients to determine if the resource has changed since it was last requested.

Example 1: Last-Modified: Tue, 04 May 2023 16:00:00 GMT
Example 2: Last-Modified: Wed, 03 May 2023 10:30:00 GMT
Example 3: Last-Modified: Mon, 01 May 2023 00:00:00 GMT

ETag

This header provides a unique identifier for the content being sent in the response. This can be used by clients to determine if the resource has changed since it was last requested, without having to download the entire resource again.

Example 1: ETag: "abc123"
Example 2: ETag: "xyz789"
Example 3: ETag: "efg456"

Access-Control-Allow-Origin

This header is used to specify which domains are allowed to access the resource being requested, in the case of cross-origin requests. This can help prevent malicious scripts from accessing resources that they should not have access to.

Example 1: Access-Control-Allow-Origin: https://www.example.com
Example 2: Access-Control-Allow-Origin: *
Example 3: Access-Control-Allow-Origin: https://api.example.com

X-Frame-Options

This header is used to prevent clickjacking attacks by restricting which sites are allowed to embed the page in an iframe. The value of the header can include “deny” to prevent embedding on any site, “sameorigin” to allow embedding only on the same domain, or a specific domain to allow embedding on that domain only.

Example 1: X-Frame-Options: SAMEORIGIN
Example 2: X-Frame-Options: DENY
Example 3: X-Frame-Options: ALLOW-FROM https://www.example.com

X-XSS-Protection

This header is used to enable or disable cross-site scripting (XSS) protection in the client’s browser. The value of the header can include “1” to enable protection or “0” to disable it.

Example 1: X-XSS-Protection: 1; mode=block
Example 2: X-XSS-Protection: 0
Example 3: X-XSS-Protection: 1; report=https://www.example.com/report

Referrer-Policy

This header is used to control how much information is sent in the referrer header when a user clicks on a link. The value of the header can include “no-referrer” to send no referrer information, “same-origin” to send referrer information only for same-origin requests, or “strict-origin” to send referrer information only for requests to the same domain.

Example 1: Referrer-Policy: strict-origin-when-cross-origin
Example 2: Referrer-Policy: no-referrer
Example 3: Referrer-Policy: origin

X-Forwarded-For

This header is used to identify the original IP address of a client that is connecting to a web server through a proxy or load balancer. When a request passes through a proxy or load balancer, the IP address of the client is usually replaced with the IP address of the proxy or load balancer. By setting this header, the proxy or load balancer can add the original IP address of the client to the request headers, allowing the server to identify the client.

Example 1: X-Forwarded-For: 192.168.1.1
Example 2: X-Forwarded-For: 192.168.1.1, 10.0.0.1
Example 3: X-Forwarded-For: 192.168.1.1, 10.0.0.1, 172.16.0.1

X-Powered-By

This header identifies the technology stack or software used to generate the response. While this header can provide useful information for developers and system administrators, it can also be a security risk if it reveals sensitive information about the server. For this reason, it is often recommended to remove this header or obfuscate its value.

Example 1: X-Powered-By: PHP/7.4.16
Example 2: X-Powered-By: ASP.NET
Example 3: X-Powered-By: Express

Keep-Alive

This header is used to enable persistent connections between the client and the server, allowing multiple requests and responses to be sent over a single TCP connection. By keeping the connection open, the overhead of establishing a new connection for each request can be avoided, improving performance. The header value can specify the maximum number of requests that can be sent over a single connection or the maximum amount of time that a connection can be idle before it is closed.

Example 1: Keep-Alive: timeout=5, max=100
Example 2: Keep-Alive: timeout=10, max=50
Example 3: Keep-Alive: timeout=15, max=200

Conclusion

In conclusion, HTTP response headers provide valuable information about the data being sent in the response from the server to the client. By understanding these headers and