jd five

Headers, Cookies & Caching

Learning goals

Use the headers that matter most in production—Host, Content-Type, Authorization, Cache-Control, and cookie headers—correctly; understand how HTTP caching behaves; and clearly separate cookies (application session identifiers) from TLS (transport encryption keys).

Headers: metadata that changes behavior

Headers are case-insensitive Name: value lines. Many are optional; some are required for correct behavior in modern HTTP.

Think of headers as instructions riding alongside the method and URL: what format the body is in, who is calling, whether this response can be stored, and how long.

Host

Required in HTTP/1.1 for virtual hosting—one IP serves many sites.

GET /networking/learn/ HTTP/1.1
Host: learning.jdfive.com

Plain English: the TCP connection might go to 203.0.113.10, but Host tells the server which website you want. Wrong or missing Host → wrong vhost or 400 from strict servers.

Behind reverse proxies, X-Forwarded-Host (or Forwarded standard) may carry the original host—configure carefully to avoid host-header injection.

Content-Type

Declares how to interpret the body.

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

Client sends on requests with bodies; server sends on responses. Mismatch (application/json body with text/plain header) breaks parsers and security filters.

Related: Content-Length (size in bytes) or Transfer-Encoding: chunked for streaming bodies without known length upfront.

Authorization

Carries credentials—not the same as TLS client certificates (rare on public web).

Common patterns:

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Authorization: Basic dXNlcjpwYXNzd29yZA==

Plain English: TLS protects bytes on the wire; Authorization tells the application who the user is. You need both on HTTPS APIs: encryption in transit + app-level auth.

401 responses often include WWW-Authenticate describing accepted schemes. APIs usually return JSON error bodies instead of browser basic-auth prompts.

Cache-Control

Controls caching by browsers, CDNs, and intermediaries.

Cache-Control: no-store
Cache-Control: max-age=3600, public
Cache-Control: private, max-age=0, must-revalidate
Directive Effect
no-store Do not persist anywhere (sensitive data)
no-cache May store but must revalidate before use
max-age=N Fresh for N seconds
private Only browser cache, not shared CDN
public Shared caches may store

ETag / Last-Modified enable conditional requests:

If-None-Match: "abc123"
→ 304 Not Modified (no body, save bandwidth)

Plain English: static assets (/static/app.js) get long max-age; personalized HTML often private or no-store.

Server sets state on the client:

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

Client sends back:

Cookie: session_id=abc123

Important attributes:

  • HttpOnly — JavaScript cannot read (mitigates XSS token theft).
  • Secure — sent only over HTTPS.
  • SameSite — cross-site request behavior (Lax, Strict, None).
  • Domain / Path — scope of send.

Cookies are opaque identifiers or small payloads—the server (or signed JWT in a cookie) maps them to session data. They are not encryption keys for TLS.

Cookies ≠ TLS keys (reinforcement)

Cookies TLS
Layer HTTP application Transport security
Purpose Session, preferences, tracking Encrypt & authenticate channel
Who sets Server Set-Cookie (JS document.cookie too) Handshake derives session keys
Visible to App code (unless HttpOnly) OS/crypto stack, not your JS
Stolen if… XSS, physical access, malware Compromised device or broken cert trust

Chapter 2 showed TLS negotiating symmetric keys for the connection. Session cookies prove identity to your backend after TLS already hid the traffic from Wi‑Fi eavesdroppers. Confusing the two leads to bad advice like “we use cookies so we are encrypted”—you still need HTTPS; cookies do not replace TLS.

Other headers worth knowing

  • Accept / Accept-Encoding — client capabilities (gzip, br).
  • Location — redirect target with 3xx.
  • Vary — cache key dimensions (e.g. Accept-Encoding).
  • Referer — previous page (privacy-sensitive).
  • User-Agent — client identification ( easily spoofed).

Common mistakes (beginners)

  1. Storing secrets in non-HttpOnly cookies — XSS can exfiltrate them.
  2. Secure cookie over HTTP in dev — cookie never sent; use HTTPS locally or relax in dev only.
  3. Caching authenticated responses without private or no-store — CDN serves one user’s page to another.
  4. Assuming Cache-Control: no-cache means “don’t cache.” — It means “revalidate before use”; use no-store to forbid storage.
  5. Omitting Host in hand-crafted HTTP/1.1 requests — virtual hosts break.

Practice checkpoint

  1. Why is Host required on HTTP/1.1?

    • Answer: Multiple domains share one IP; Host selects the correct site configuration.

  2. Cache-Control: no-store vs no-cache?

    • Answer: no-store forbids storing the response; no-cache allows storage but requires validation before reuse.

  3. Does a session cookie encrypt HTTP traffic?

    • Answer: No. TLS encrypts the connection; cookies are application-layer identifiers sent inside that tunnel.

  4. Name three useful Set-Cookie security attributes.

    • Answer: HttpOnly, Secure, SameSite (any three of Domain/Path/Max-Age also valid if security-focused).

Interview angles

  • “How do CDNs cache HTML vs API JSON?” — Cache-Control, Vary, cookies on requests (cookies often make responses uncacheable at edge unless keyed carefully).
  • “Cookie vs token in Authorization header?” — Cookies auto-sent by browser (CSRF considerations); Bearer tokens in header common for SPAs/mobile with explicit CORS.
  • “What happens if you set max-age=86400 on a personalized dashboard?” — Browser may show stale personalized content; use private or no-store for user-specific pages.

Next: /networking/learn/transport/tcp-beyond-basics/