AUTH_SESSION_ID, KC_RESTART, identity/session cookies
Redirect state bursts
Clear transient cookies quickly
Home Assistant Auth
Session and trusted network tokens
Home lab proxy path
Test through the exact proxy chain
💡 Cookie Header Sizing Tips
Separate response and request math: Set-Cookie includes attributes such as Secure, HttpOnly, SameSite, Path, Domain, Expires, and Max-Age. Later Cookie request headers usually send only name=value pairs, so the repeated payload is smaller but appears on many more requests.
Size for the smallest hop: A browser may store the cookie, but Nginx, Apache, an ingress controller, a CDN, or an upstream app server can still reject the request header. Keep a buffer for User-Agent, Accept, Authorization, tracing, and forwarding headers.
Keep JWT cookies boring: Do not place profile data, roles arrays, feature flags, or verbose claims in every request unless you truly need them at the edge. Short opaque session identifiers usually win for header size.
Do not trust compression for limits: HPACK and QPACK can reduce repeated wire traffic, but storage and parsing limits are normally based on the header field data the endpoint sees. Use compression only as a traffic estimate.
A new authentication flow is deployed. Nothing loads. The login page spin. The API return some vague error. Logs show that something in headers are getting silently truncated. Why? Because cookies are not an infinite size.
Cookies live within HTTP request header. Every click on your site send those headers along for the ride. Reverse proxies (e.g., Apache or Nginx) will rejects connections if those header grow too large. The request doesn’t even make it to your application code. It’s not that you broke the logic, you broke the envelope.
Keep Cookies Small
Developers forget that math is simple: Most developers focus on the forty-kilobyte-per-domain storage limit and assume they has plenty of room to store session tokens or user preferences directly in the browser. But this assumes that bandwidth cost isn’t an issue and it fails to consider the cost of sending all those cookies back to the server on every page view. With ten cookies at an average of two kilobytes apiece, that’s twenty kilobytes of extra data being sent by the browser during each request. Then there are other standard header such as Accept-Encoding and User-Agent which takes up space. In many proxy configs, that can easily push past the default of eight kilobytes.
Use page’s calculator. It’ll crunch the numbers for you. You won’t have to guess about header overhead anymore. Know your measure. Attributes such as Domain, Path, SameSite, Secure and HttpOnly is all part of the Set-Cookie response. They carry some weight on the first handshake. But there’s no repetition in the cookie header sent by the browser. Only its value are included.
But if that value happens to be a large JSON Web Token with long claims, this value will repeat on each subresource load. Stylesheets and images share same domain. This triggers these requests. That’s where people go wrong; they reduce storage space, but they forget that the value is sent repeatedly through bandwidth.
Consider a plane and your luggage. Maybe you can bring 20 bags onto a plane, but not all of them will fit under seat. In the same way, browsers can handles big cookies individually, but the infrastructure have tight limits on the total size of headers. Three to four kilobytes each is a good target. To help with this, make auth tokens small. Only keep an opaque ID on client side. Then store the real session info in some kind of Redis cache or server-side DB. This dramatically cuts down on what’s being sent back and forth repeatedly.
Different browsers has different limits, as shown in the reference table. Even with those limits, the proxy can be the limiting factor. Repeated fields gets compressed (e.g., via HTTP/2 HPACK, HTTP/3 QPACK) which reduces wire traffic. This doesn’t alter what’s important: the limits of storage and parsing. Most proxies has limits on uncompressed header size. The proxy inspects the uncompressed size before it decompress. It’s risky engineering to assume your compression would of save you from a bloated header; always plan for the largest possible uncompressed size.
When setting up your app think about how many domains it serves. A cookie set with a broad domain like.example.com will be sent to cdn.example.com and api.example.com, unless scoped closely. Limit the domain attribute to reduce needless traffic. Be mindful of third party services which also sets their own cookies. These increase size of the header payload.
Next time your site seems sluggish or unresponsive under load, examine its cookie footprint first. Don’t suspect the DB is lagging. You want to fit with a limit, but leave headroom for growth. What if some tracing system or security tool need more headers? Ten to twenty percent is good insurance in production. Add user agents or monitoring tags without wondering whether you’ll get rejected.
Keep your state small so your authentication is invisible and efficient. That’s the ceiling, the smallest hop in your network chain. If you respect it, then your requests will go through smoothly; they won’t be caught at the gate. Actualy, if you follow this, it should work fine. It’s more comfortabley than working with errors. The moddern way is to keep headers slim so things dont dissapears.
