04: HTTP Headers - HTTP Tutorials

What Are HTTP Headers?

HTTP headers are key-value pairs that provide additional information about a request or response. They appear after the request/status line and before the body:

Headers control caching, authentication, content types, cookies, and much more. Understanding headers is essential for debugging HTTP issues and building robust web applications.

Header Categories

HTTP headers are traditionally grouped into four categories:

Category	Description	Examples
General	Apply to both requests and responses	Date, Connection, Cache-Control
Request	Provide info about the request or client	Host, User-Agent, Accept, Cookie
Response	Provide info about the response or server	Server, Set-Cookie, WWW-Authenticate
Entity	Describe the body content	Content-Type, Content-Length, Content-Encoding

General Headers

These headers apply to both requests and responses, providing general information about the message.

Date

The date and time the message was sent:

Date: Tue, 26 Nov 2024 15:30:00 GMT

Always in GMT format. Required in responses; optional in requests.

Connection

Controls whether the network connection stays open:

Connection: keep-alive Connection: close

keep-alive allows multiple requests over one TCP connection (HTTP/1.1 default). close signals the connection will close after this exchange.

Cache-Control

Directives for caching mechanisms:

Cache-Control: public, max-age=3600 Cache-Control: no-store Cache-Control: private, no-cache

public: Can be cached by any cache
private: Only browser can cache (not CDNs/proxies)
no-cache: Must revalidate before using cached copy
no-store: Never store the response
max-age=N: Cache is valid for N seconds

Request Headers

These headers provide information about the request being made or the client making it.

Host

The domain name and port of the server (required in HTTP/1.1):

Host: www.example.com Host: api.example.com:8080

Essential for virtual hosting—multiple websites on the same IP address.

User-Agent

Information about the client making the request:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36

Used for analytics, content adaptation, and (unfortunately) browser sniffing.

Accept

Media types the client can handle:

Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8

The q value (0-1) indicates preference. Higher = more preferred.

Accept-Language

Preferred languages for the response:

Accept-Language: en-US, en;q=0.9, es;q=0.8

Enables serving content in the user's preferred language.

Accept-Encoding

Compression algorithms the client supports:

Accept-Encoding: gzip, deflate, br

br is Brotli compression, often more efficient than gzip.

Authorization

Credentials for authenticating the client:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ= Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Common schemes: Basic (base64 encoded), Bearer (tokens), Digest.

Cookie

Previously stored cookies sent back to the server:

Cookie: session_id=abc123; user_pref=dark

Multiple cookies are separated by semicolons.

Referer

The page that linked to the requested resource:

Referer: https://www.example.com/page.html

Yes, "Referer" is a misspelling of "referrer" but it's been in the spec since the beginning.

If-None-Match / If-Modified-Since

Conditional request headers for caching:

If-None-Match: "abc123" If-Modified-Since: Mon, 25 Nov 2024 10:00:00 GMT

If the resource hasn't changed, the server returns 304 Not Modified.

Response Headers

These headers provide information about the response or the server.

Server

Information about the server software:

Server: nginx/1.18.0 Server: Apache/2.4.41 (Ubuntu)

Some administrators hide this for security reasons.

Set-Cookie

Instructs the client to store a cookie:

Set-Cookie: session_id=xyz789; Path=/; HttpOnly; Secure; SameSite=Strict

Path: URL path the cookie applies to
HttpOnly: JavaScript cannot access the cookie
Secure: Only send over HTTPS
SameSite: Controls cross-site requests (Strict, Lax, None)
Max-Age or Expires: When the cookie expires

Location

URL to redirect to (used with 3xx status codes) or new resource location (201):

Location: https://www.example.com/new-page.html

WWW-Authenticate

Defines the authentication method for accessing a resource (with 401):

WWW-Authenticate: Bearer realm="api", error="invalid_token"

ETag

A unique identifier for a specific version of a resource:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Used for cache validation with If-None-Match.

Allow

Lists valid HTTP methods for a resource (used with 405):

Allow: GET, POST, HEAD, OPTIONS

Retry-After

How long to wait before retrying (used with 429, 503):

Retry-After: 120 Retry-After: Tue, 26 Nov 2024 16:00:00 GMT

Entity Headers

These headers describe the body of the message.

Content-Type

The media type of the body:

Content-Type: text/html; charset=UTF-8 Content-Type: application/json Content-Type: multipart/form-data; boundary=----WebKitFormBoundary

This is crucial—it tells the recipient how to interpret the body.

Content-Length

The size of the body in bytes:

Content-Length: 3495

Allows the recipient to know when the body is complete.

Content-Encoding

The compression applied to the body:

Content-Encoding: gzip Content-Encoding: br

Must match what the client indicated in Accept-Encoding.

Content-Language

The natural language of the intended audience:

Content-Language: en-US

Content-Disposition

Suggests how to handle the content (inline or download):

Content-Disposition: attachment; filename="report.pdf" Content-Disposition: inline

attachment triggers a download; inline displays in browser.

Last-Modified

When the resource was last changed:

Last-Modified: Mon, 25 Nov 2024 10:00:00 GMT

Used for cache validation with If-Modified-Since.

Content Negotiation

Content negotiation allows clients and servers to agree on the best representation of a resource. The client expresses preferences; the server chooses the best match.

How It Works

Client sends Accept-* headers with preferences
Server evaluates available representations
Server selects the best match based on quality values
Response includes headers indicating what was chosen

Quality Values

The q parameter (0.0 to 1.0) indicates preference:

Accept: text/html, application/xml;q=0.9, text/plain;q=0.8, */*;q=0.1

Higher q = more preferred. Default is 1.0 if omitted.

Caching Headers

Proper caching headers dramatically improve performance and reduce server load.

Cache-Control Directives

Directive	Meaning
public	Any cache can store the response
private	Only browser cache (not CDN/proxy)
no-cache	Must revalidate before using
no-store	Never cache (sensitive data)
max-age=N	Fresh for N seconds
s-maxage=N	Fresh for N seconds in shared caches
must-revalidate	Can't use stale after max-age
immutable	Content will never change

Validation with ETag

Server sends response with ETag: "abc123"
Browser caches the response with the ETag
Later: browser sends If-None-Match: "abc123"
If unchanged: server returns 304 (use cache)
If changed: server returns 200 with new content and ETag

Interactive Examples

The following examples demonstrate various HTTP headers in context.

Content Negotiation

Client requests JSON; server responds accordingly:

Compressed Response

Server compresses the response based on Accept-Encoding:

Cache Validation (304)

Client validates cached content using ETag:

File Download

Server triggers download with Content-Disposition:

Setting Cookies

Server sets multiple cookies with various attributes:

CORS Headers

Server allows cross-origin requests: