What does Go's http.SetCookie do to a cookie value containing a space, a semicolon or a quote?

## Sanitising is not escaping A cookie value lives in a header whose grammar reserves several characters — `;` separates attributes, `,` separates cookies in some contexts, `"` delimits a quoted value, and control characters could split the header entirely. A library has three options: reject, escape, or strip. Go strips. When `http.SetCookie` formats the struct, the value goes through a sanitiser that walks the bytes and keeps only the legal ones. Roughly, a byte is legal if it is printable ASCII and is not `"`, `;` or `\`. Everything else is **removed from the value**, and `net/http` logs a line through the standard logger saying it found an invalid byte and is dropping invalid bytes. It does not percent-encode, it does not backslash-escape, and it does not return an error — `http.SetCookie` has no error to return. So this: ```go c := &http.Cookie{Name: "pref", Value: "dark mode; drop=me"} ``` loses the semicolon and becomes `dark mode drop=me`, which then gets quoted (see below) and is emitted as `pref="dark mode drop=me"`. The value that comes back on the next request is not the value you set — a real source of "the token in the database does not match the token in the cookie" bugs when someone puts structured text straight into a cookie. ## Quoting After stripping, if what remains contains a **space or a comma**, Go wraps the whole thing in double quotes. That is the only condition; nothing else triggers quoting. `Value: "a b"` produces `name="a b"`, while `Value: "a-b"` produces `name=a-b`. The reverse direction handles this too: when Go parses an inbound cookie whose value is wrapped in double quotes, it removes them and sets the `Quoted` field on the `http.Cookie` to true, so the parsed `Value` is the clean text. Re-emitting that struct puts the quotes back, which keeps a proxy or a test round trip faithful. You can set `Quoted` yourself to force quoting on a value that would not otherwise need it. ## The name is stricter, and fails silently A cookie **name** must be a valid HTTP token: no spaces, no `=`, no separators, no control bytes. Go does not sanitise a bad name into a good one. `(*http.Cookie).String()` returns the empty string, and `http.SetCookie` only adds a header when `String()` is non-empty — so an invalid name means **no `Set-Cookie` header at all**. There is no error, no panic, and the handler proceeds as if everything worked. `Name: "user id"` is a header that never appears. (The name does get one small fix-up: carriage returns and newlines are replaced with `-` rather than dropped, specifically so a name can never split the header.) ## How to find out that it happened Three tools, in increasing order of effort: 1. `(*http.Cookie).Valid() error` checks the struct and tells you *which* field is wrong — name, value bytes, path, domain or expires. Nothing calls it for you; call it yourself when the value comes from anywhere but a constant. 2. `(*http.Cookie).String()` gives you the exact header line `SetCookie` would emit. Printing or asserting it in a test is the fastest way to see a dropped byte. 3. The dropped-byte log line goes to the standard logger, so it appears in the server's output — worth grepping for when a value mysteriously changes shape. ## The rule that avoids the whole area Do not put arbitrary text in a cookie value. Encode it: - `base64.RawURLEncoding.EncodeToString(b)` for opaque bytes — the alphabet is entirely legal in a cookie and needs no quoting. - `url.QueryEscape(s)` for text you want to read back with `url.QueryUnescape`. - Anything structured — JSON, a struct, several fields — is better encoded once and decoded once than shoved in raw, because the sanitiser will happily eat the punctuation that gives it structure. With an encoded value, quoting never triggers, nothing is ever dropped, and what you read back is byte-for-byte what you wrote.