All About HTTP Headers

I’ve been working with APIs for the last 4 years, and a lot of that work has involved HTTP in one way or another.

Over time, I learned the things I needed on a daily basis, but when it came to understanding the small details and nitty-gritties of HTTP headers, I kept procrastinating.

So today, I finally decided to sit down and learn more about them properly.

I’m also making these notes so I can come back to them in the future, and hopefully they might be useful to someone else who wants to understand HTTP headers a little better.

Let’s dive into it.

HTTP headers are basically key-value pairs that carry metadata along with an HTTP request or response.

They help the client and server communicate extra information with each other, like how to interpret the data, how to authenticate the request, whether something should be cached, what type of content is being sent, and a lot more.

In simple terms, the body contains the actual data, while the headers provide extra context about that data and the request or response itself.

For example, an HTTP request might look like this:

GET /users/123 HTTP/1.1
Host: abhay.example.com
Authorization: Bearer <token>
Accept: application/json
User-Agent: MyApp/1.0

The headers are everything between the request line and the blank line before the body

Request Headers

these headers describe the client and what it wants

Some important request headers are:

• Authorization: Sends credentials or an access token
• Accept: Tells the server which response formats are acceptable by client
• Content-Type: Describes the format of the request body
• User-Agent: Identifies the client/browser/app
• Cookie: Sends stored cookies back to the server
• If-None-Match: User with ETag for conditional caching
• Referer: Indicates the page that initiated the request
• Origin: Important for browser CORS checks

please try to understand the difference between Accept and Content-Type

Example of a request:

POST /users HTTP/1.1
Authorization: Beared <token>
Content-Type: application/json
Accept: application/json
Cookie: asdasdasdasdasdasdaaaaaaaa
User-Agent: Chrome/1.0

{
  "name": "Alice"
}

Response Headers

response headers describe the server’s response and tell the client how to handle it.

Some important response headers are:

• Content-Type: Format of the response body
• Content-Length: Size of the response body in bytes
• Cache-Control: Rules for caching the response
• ETag: Identifier/version for a particular response representation
• Set-Cookie: Instructs the browser to store a cookie
• Location: Where to redirect, commonly with 301, 302, or after resource creation
• WWW-Authenticate: Tells the client which authentication method is required
• Access-Control-Allow-Origin: Part of browser CORS handling

Example of a Response:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=3600
ETag: "v123"
Set-Cookie: session=xyz; HttpOnly; Secure

{
  "id": 123,
  "name": "Alice"
}

Headers and Authentication

Almost everyone is aware of Authorization header having Bearer token and stuff. The server reads it and determines the user and the permissions the user have.

Note: You should never ever use URL params to send secret tokens.

Headers and Caching

Headers are also central to HTTP caching

Ex:

Cache-Control: max-age=3600
ETag: "user-123-v5"

means the response may be reused for up to an hour, and “user-123-v5” identifies that version of the representation.

Later, the browser might send:

If-None-Match: "user-123-v5"

If nothing changed, the server can respond:

HTTP/1.1 304 Not Modified

with no full response body. That saves bandwidth.

Cookies are implemented through headers

The server creates a cookie using a response header:

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax

The browser stores it and later sends:

Cookie: sessionId=abc123

So the flow is essentially:

Server → Set-Cookie header → Browser stores cookie

Browser → Cookie header → Server receives cookie

Flags such as HttpOnly, Secure, and SameSite are particularly important for cookie security.

Headers and CORS

Browsers use headers to enforce Cross-Origin Resource Sharing.

Suppose JavaScript running at:

https://frontend.example.com

calls:

https://api.example.com

The browser might send:

Origin: https://frontend.example.com

and the API might respond:

Access-Control-Allow-Origin: https://frontend.example.com

If the appropriate CORS headers aren’t present, the browser can prevent JavaScript from accessing the response even though the HTTP request reached the server.

Custom headers

Applications can define their own headers:

X-Request-ID: a72b91
X-API-Version: 2

Modern APIs sometimes avoid the old X- convention and simply use names such as:

Request-Id: a72b91

Custom headers are frequently used for tracing, API versions, correlation IDs, or application-specific metadata.

One subtle point: HTTP header names are case-insensitive. These are equivalent:

Content-Type
content-type
CONTENT-TYPE

HTTP/2 and HTTP/3 typically transmit header names in lowercase.

The easiest mental model is:

HTTP message
│
├── Start line
│   GET /users HTTP/1.1
│
├── Headers
│   Authorization: Bearer ...
│   Accept: application/json
│   Content-Type: application/json
│
└── Body
    {"name": "Alice"}

So:
start line = what operation happened,
headers = instructions/metadata,
body = the actual payload.

Here’s a gift for you :)