Content-Type

This is perhaps the most critical representation header. It tells the recipient the media type of the resource in the message body. This information is crucial for the client to process the content correctly. For example, a browser needs to know whether it's receiving an HTML document to render, a CSS file to apply styles, a JavaScript file to execute, or an image file to display.

The value of this header is a MIME type, often followed by additional directives.

Common MIME Types:

• text/html: For standard webpages.
• text/css: For stylesheets.
• application/javascript: For JavaScript code.
• application/json: For data in JSON format, common in APIs.
• image/jpeg, image/png: For images.
• multipart/form-data: For form submissions that include file uploads.

Directives:

Directives are additional parameters. The most common is charset, which specifies the character encoding used (e.g., $UTF-8$).

Content-Type: text/html; charset=UTF-8

Content-Length

This header indicates the size of the message body in bytes (as a decimal number). It is a straightforward but vital piece of information. The recipient uses this value to know exactly how much data to read from the network connection to get the complete message body. Without it, the recipient would have to wait for the server to close the connection to know that the message is complete, which is inefficient.

Content-Length: 1548

Content-Encoding

This header specifies the compression algorithm that has been applied to the message body. To save bandwidth and improve loading times, servers often compress data before sending it. The browser, upon seeing this header, knows it must decompress the body before it can be used.

Common Encodings:

• gzip: A widely supported and effective compression format.
• deflate: Another common compression algorithm.
• br: Brotli, a newer algorithm developed by Google, often offering better compression than gzip.

Content-Encoding: gzip

Host

The Host header is mandatory in all HTTP/1.1 requests. It specifies the domain name of the server the client is trying to reach, and optionally the port number. This header is what makes virtual hosting possible. A single server with a single IP address can host hundreds of different websites. When a request arrives at the server, it uses the Host header to determine which website the request is intended for and serves the appropriate content.

Host: www.example.com

Accept-* Headers and Content Negotiation

A powerful feature of HTTP is content negotiation. This allows a client to specify its preferences for the type of content it can handle, and the server can then select the most appropriate representation of a resource to send back. This is primarily done using a set of Accept-* headers.

• Accept: Tells the server which media types (MIME types) the client can understand. For example, a browser might indicate it can handle HTML, XML, and images.
• Accept-Language: Informs the server about the user's preferred language(s). This allows a server to respond with a page in English, French, or Spanish based on the user's browser settings.
• Accept-Encoding: Informs the server which compression algorithms the client supports.

Clients can also specify their preferences using a quality value (q-factor), a number between 0 and 1. A higher number indicates a higher preference. For instance, Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5 means the client prefers Swiss French, followed by any French, then English, then German, and finally any other language as a last resort.

Authorization

This header is the standard way to provide credentials for authenticating a client with a server. There are several authentication schemes. The two most common are:

• Basic: This scheme sends a username and password encoded with Base64. It is not secure because Base64 is easily decoded, and the credentials are sent as plain text. It should only be used over an HTTPS connection.

  Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

• Bearer: This is the scheme used in modern web applications, particularly with frameworks like OAuth 2.0. The client sends a cryptic token (like a JSON Web Token or JWT) which the server can validate to grant access. The token itself is obtained through a separate login process.

  Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Cache-Control

This is the most important and modern response header for specifying caching policies. It is a general header but is most powerful in responses. It can contain a variety of directives:

• public: The response may be stored by any cache, including shared proxies.
• private: The response is intended for a single user and must not be stored by a shared cache. The user's private browser cache can still store it.
• no-store: The response cannot be cached anywhere. This is for highly sensitive data.
• no-cache: This directive is often misunderstood. It does not mean "do not cache". It means that the cache must revalidate with the origin server before using a cached copy. It forces the cache to check if the resource has changed using validation headers like ETag.
• max-age=$seconds$: Specifies the maximum amount of time in seconds that a resource is considered fresh. For this duration, the browser can use the cached copy without contacting the server.

# Cache this image in all caches for one year
Cache-Control: public, max-age=31536000

# Cache user-specific data in the browser for one hour
Cache-Control: private, max-age=3600

# Always check with the server before using the cached HTML
Cache-Control: no-cache

ETag and If-None-Match (Validation)

When a max-age expires, the cached content is considered stale. However, the resource on the server may not have actually changed. To avoid re-downloading the entire file, HTTP provides a validation mechanism.

1. The server includes an ETag (Entity Tag) header in its initial response. The ETag is a unique identifier or hash for a specific version of the resource.
2. When the browser needs to re-validate the stale resource, it makes a conditional GET request and includes the ETag value in an If-None-Match request header.
3. The server checks the client's ETag against the current version of the resource. If they match, the resource has not changed. The server responds with a special 304 Not Modified status and an empty body. The browser then knows it can safely use its cached copy for another period. This saves significant bandwidth.