HTTP Headers and Cookies Decoded: Request, Response, and Set-Cookie

Every HTTP exchange is a bag of headers plus an optional body. Auth tokens hide in Authorization. Caching lives in Cache-Control and ETag. Sessions ride on Set-Cookie. When something breaks — CORS, login loops, stale cache — the answer is almost always in the header block, not the JSON payload. This guide maps the headers that matter, how cookies actually work, and why parsing User-Agent strings is riskier than it looks.

Bottom line: Treat headers as the control plane of HTTP. Learn the request/response split, read every Set-Cookie attribute before shipping auth, and never trust User-Agent alone for capability or security decisions. Parse raw dumps with browser tools or a HTTP Header Parser when debugging.

Request vs response: who sends what

Direction	Examples	Purpose
Request	Host, Accept, Authorization, Cookie, User-Agent	What the client wants and who it claims to be
Response	Content-Type, Set-Cookie, Cache-Control, Location	What the server returns and how the client should behave

A single round-trip looks like this (simplified):

GET /api/profile HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGciOi...
Cookie: session=abc123; theme=dark
User-Agent: Mozilla/5.0 (...)

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: private, max-age=60
Set-Cookie: session=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

Paste either block into a HTTP Header Parser to split names, values, and multi-value fields without guessing where one header ends.

Headers you will debug weekly

Header	Side	Common failure mode
Authorization	Request	Missing Bearer prefix; leaked in logs
Content-Type	Both	Client sends JSON as text/plain; server rejects
Accept	Request	Server returns HTML error pages to API clients
Cache-Control / ETag	Response	Stale auth pages; aggressive CDN cache
Access-Control-*	Response	CORS preflight fails; credentials mismatch
Location	Response	Redirect drops auth headers or changes host
Cookie / Set-Cookie	Both	Path/domain mismatch; Secure on HTTP localhost

Hop-by-hop headers (Connection, Transfer-Encoding, Keep-Alive) are handled by proxies — rarely your app's concern unless you are building one.

Cookie anatomy: more than name=value

Browsers send cookies in the request Cookie header. Servers create or update them with Set-Cookie. A Cookie Parser turns a raw string into structured attributes so you can audit security flags at a glance.

Request Cookie header

Cookie: session=abc123; theme=dark; _ga=GA1.2.xxx

Multiple cookies are semicolon-separated. There is no standard for nested structure — treat each pair as opaque.

Response Set-Cookie attributes

Set-Cookie: session=abc123; Path=/; Domain=.example.com; Max-Age=3600; HttpOnly; Secure; SameSite=Lax

Attribute	Effect
Path	URL path prefix where the cookie is sent
Domain	Host (and subdomains if leading dot / domain attribute set)
Max-Age / Expires	Lifetime; omit both for session cookie
HttpOnly	Not readable from document.cookie (mitigates XSS theft)
Secure	Sent only over HTTPS
SameSite	Strict, Lax, or None (None requires Secure)
Partitioned	CHIPS — third-party cookie in a partitioned jar

SameSite in practice

Value	Cross-site behavior	Typical use
Strict	Never sent on cross-site navigations	High-security session
Lax (default in modern browsers)	Sent on top-level GET navigations	Most app sessions
None	Sent in cross-site requests if Secure	Embedded widgets, some SSO

CSRF protection still needs tokens or careful SameSite design. SameSite is not a complete CSRF solution for every API shape.

Debugging cookie bugs

1. Confirm the cookie appears under Application → Cookies for the exact host.
2. Check Path — /api cookies are not sent to /.
3. Check Secure — http://localhost may need exceptions or localhost HTTPS.
4. Check SameSite=None without Secure — browsers reject it.
5. Compare Set-Cookie from the network panel with what a Cookie Parser extracts.

User-Agent: useful metadata, bad security signal

The User-Agent header is a free-form string browsers and clients send to describe themselves. A User-Agent Parser extracts browser family, OS, and device hints for analytics and support tickets.

Example:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36

What parsing is good for

• Support triage ("which browser version hit this bug?")
• Coarse analytics (mobile vs desktop share)
• Feature messaging ("update Chrome to use this API")

Caveats that bite teams

Trap	Why it fails
Capability sniffing	UA lies; feature detection ('serviceWorker' in navigator) is correct
Security decisions	Trivially spoofed; never gate auth or admin by UA
Bot blocking by UA alone	Scrapers copy real Chrome strings
Reduced UA / Client Hints	Chromium ships a frozen or reduced UA; use Client Hints (Sec-CH-UA-*) when you need structured data
Regex rot	New browser versions break brittle parsers monthly

Prefer Client Hints and feature detection for product logic. Keep UA parsing for logging and human-readable support context.

A practical header debugging workflow

1. Reproduce in DevTools Network — copy the failing request as cURL or "Copy as fetch".
2. Paste response headers into HTTP Header Parser; note Cache-Control, CORS, and redirects.
3. Extract every Set-Cookie with Cookie Parser; verify HttpOnly, Secure, SameSite.
4. If device-specific, parse UA with User-Agent Parser — then confirm with a second browser before blaming "Safari only."
5. Fix the server config or proxy; re-test with an empty cookie jar.

Quick mental model for auth

Mechanism	Header / cookie	Notes
Bearer JWT	Authorization: Bearer …	Stateless API; watch logging
Session cookie	Set-Cookie + Cookie	Prefer HttpOnly + Secure + SameSite
API key	Custom (X-Api-Key) or query	Prefer header over query (query leaks in logs)

Never put long-lived secrets in URLs. Prefer headers or HttpOnly cookies.

CORS and cookies together

Cross-origin requests with credentials require:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true

Allow-Origin cannot be * when credentials are true. Cookies need a compatible SameSite (often None; Secure for true cross-site) and matching Domain. Misconfigured CORS plus cookies is the classic "works on same origin, fails in production" bug.

Practical takeaway

Read headers before you rewrite application code. Use a HTTP Header Parser on raw dumps, a Cookie Parser to audit every Set-Cookie flag, and a User-Agent Parser only for support context — not security gates. Default sessions to HttpOnly; Secure; SameSite=Lax, tighten to Strict when UX allows, and reserve None for deliberate cross-site cases.

Sources

• MDN: HTTP headers
• MDN: Set-Cookie
• RFC 6265bis — Cookies
• MDN: User-Agent
• web.dev: SameSite cookies explained