Cookie jar

A cookie jar is the store a client keeps of the cookies it has received, keyed by domain and path, and replayed on later requests that match. It is the mechanism that turns stateless HTTP requests into something a server can recognise as a continuing session.

#What the jar holds

Each entry carries a name and value plus the attributes that decide when it is sent back: the domain, the path, an expiry, and flags marking it as secure or inaccessible to scripts. A cookie is returned only when all of those match the outgoing request, which is why a jar shared across sites is not as promiscuous as it sounds.

RFC 6265 sets minimum capacities that user agents should support: at least 4096 bytes per cookie, at least 50 cookies per domain, and at least 3000 in total. Real clients differ above those floors.

#Why it matters more than the exit address

A session identifier in a jar is a far stronger identity than an address. Reusing one jar across a rotating proxy tells the target that a single client is moving between addresses, which is more distinctive than staying on one address would have been. Rotation and shared state work against each other.

The rule that follows is simple: one jar per identity, created and destroyed with the identity, never shared between them. If you want a sticky session, pin the jar and the exit together.

#Handling it explicitly

curl -c jar.txt -b jar.txt -x http://gateway.example:8000 https://example.com/

Writing the jar to a named file per identity makes the coupling visible and reviewable. Any client that keeps a default jar in a process-wide singleton will merge identities the moment you run two in one process, and the mistake produces no error.

#Commonly confused with

A session is the server’s notion of a continuing interaction; the jar is the client’s storage that sustains it. Clearing a jar does not end a session that is also tracked by fingerprinting or by an address, and a headless browser keeps state in several other places besides cookies.