Handling cookies is a minefield

Original Article ↗ Hacker News Discussion ↗

Cookie complexity and evolving standards

  • Commenters note cookies keep accreting features: SameSite, prefixes like __Host-, varying browser support and quirks.
  • Prefixes are widely supported and backward-compatible, but are opt‑in; you can ignore them if your needs are simple.
  • Some think cookies are a “minefield”; others argue if you follow the current spec carefully, it’s manageable.

Parsing differences and real‑world bugs

  • Cookie header parsing diverges between RFCs, browsers, servers, and libraries, making interoperability fragile.
  • Examples: Firefox accepting characters discouraged by the RFC; Safari being far stricter (dropping/ignoring/truncating).
  • Multiple languages/libraries (Go stdlib, Python’s cookie parser, Crystal HTTP client, certain JS libraries) have had subtle cookie bugs.
  • Several people mention production issues caused by quotes, commas, or non‑ASCII characters in cookies.

What to store in cookies (and how)

  • Many argue cookies should carry only small opaque tokens (session IDs), with all real state on the server.
  • JSON in cookies is widely seen as risky: reserved characters, parsing edge cases, header size limits.
  • Recommended mitigations: strict character sets, base64 or base64url encoding (with care to define which), and keeping values short.
  • JWTs are cited as a common workaround, though some feel they’re overused.

Path, domain, and environment pitfalls

  • Cookie “shadowing” (same name, different path/domain) leads to multiple indistinguishable values and hard‑to‑delete cookies.
  • Deleting requires matching the original path/domain exactly; if you don’t know them, you may be stuck.
  • Using Path is called a “code smell” by some, but others defend it for scoping (e.g., login-only cookies, /api‑only auth).
  • Sharing prod/staging/dev on the same registrable domain is described as a serious long‑term mistake due to cross‑env cookie leakage; separate domains/TLDs or carefully structured subdomains are recommended.

Alternatives and “new cookie” ideas

  • Suggestions include a redesigned “NewCookie” mechanism or leaning more on localStorage/sessionStorage plus service workers.
  • Objections: localStorage can’t be HttpOnly and is fully readable by JS; not suitable for secure session tokens.
  • Some propose using the Authorization header and browser‑level auth UIs, but others note this doesn’t map cleanly to today’s multi‑page flows and CSRF protections.

Postel’s law and protocol design

  • Strong disagreement over Postel’s law: some blame “be liberal in what you accept” for today’s messy ecosystems; others say the real failure is senders not being conservative.
  • One view: being too permissive entrenches non‑compliant behavior; another: strictness everywhere makes systems brittle and harder to evolve.
  • A broader idea emerges: HTTP sub‑features (like cookies) should have explicit, negotiable versions to allow evolution without breaking old clients.