HTTP State Management Mechanism
obsoletes
- rfc-2965 — HTTP State Management Mechanism
Extracted elements (31)
RFC 6265 obsoletes RFC 2965 and deprecates the Cookie2 and Set-Cookie2 header fields, because none of the prior specifications (Netscape cookie spec, RFC 2109, RFC 2965) accurately described how cookies are actually used on the Internet. The goal is to codify existing practice rather than introduce new syntax or semantics.
The specification defines two compliance targets: servers SHOULD follow a well-behaved profile (Section 4) to maximize compatibility, while user agents MUST implement more liberal processing rules (Section 5) to interoperate with servers that do not conform to that profile. This asymmetry reflects the reality that deployed servers vary widely.
Some existing user agents do not support the Max-Age attribute and will ignore it, treating the cookie as session-scoped. Servers that need cross-agent compatibility SHOULD include both Max-Age and Expires; Max-Age takes precedence in agents that support both.
Some existing user agents treat an absent Domain attribute as if it were set to the current hostname, causing them to erroneously send the cookie to subdomains. Servers relying on host-only behavior should be aware of this divergence.
Some user agents store dates in cookies as 32-bit UNIX time_t values; implementation bugs may cause incorrect processing of dates after 2038. Servers should avoid setting expiration dates beyond what such systems can reliably represent.
A string domain-matches a domain string if they are identical, or if the domain string is a suffix of the string, the preceding character in the string is a dot, and the string is a hostname (not an IP address). Both values are canonicalized to lowercase before comparison.
General-use user agents SHOULD support at least 4096 bytes per cookie (name + value + attributes combined), at least 50 cookies per domain, and at least 3000 cookies total. Servers SHOULD use as few and as small cookies as possible.
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field, because the comma character (%x2C) is used by Set-Cookie in a way that conflicts with the standard HTTP header folding mechanism.
User agents MAY ignore Set-Cookie headers in 100-level responses but MUST process Set-Cookie headers in all other responses, including 400- and 500-level status codes.
User agents MUST evict all expired cookies from the cookie store whenever an expired cookie exists. When removing excess cookies, they MUST evict in priority order: (1) expired cookies, (2) cookies from domains exceeding a per-domain limit, (3) all cookies; with earliest last-access-time broken ties.
User agents MUST implement the liberal Set-Cookie and Cookie processing rules defined in Section 5, in order to maximize interoperability with existing servers that do not conform to the well-behaved profile in Section 4.
User agents MUST parse Set-Cookie headers using a liberal algorithm that strips leading/trailing whitespace from name and value, ignores set-cookie-strings lacking an '=' character or with an empty name, and silently ignores unrecognized attribute names.
User agents MUST reject cookies whose domain-attribute, if non-empty, does not domain-match the canonicalized request-host. If configured to reject public suffixes, the user agent MUST ignore cookies with a public-suffix domain-attribute unless it equals the exact request-host.
User agents MUST use a specific lenient algorithm to parse cookie-date values, tolerating a wide range of delimiter characters and accepting 2-digit years (70–99 → 1970–1999; 0–69 → 2000–2069). Parsing fails if any of day-of-month, month, year, or time are absent, or if values are out of range.
User agents SHOULD sort cookies in the Cookie header with longer-path cookies first; among equal-path cookies, earlier creation-time first. This order is advisory but reflects common practice that some servers have historically depended on.
When the current session ends, user agents MUST remove all non-persistent cookies (persistent-flag false) from the cookie store.
Third-party cookies allow advertising networks and analytics providers to track users across unrelated sites by correlating cookies set when third-party resources are loaded. User agents are granted wide latitude to implement third-party cookie blocking policies; this document does not endorse any specific policy but notes that server-side workarounds (e.g., identifying information in URLs) can defeat blocking.
User agents SHOULD provide mechanisms for users to manage, delete, and disable cookies. When cookies are disabled, the user agent MUST NOT send Cookie headers or process Set-Cookie headers. User agents MAY support a non-persistent (private browsing) mode that treats all cookies as session cookies.
The Domain attribute specifies the hosts to which the cookie will be sent. A leading dot is ignored. If absent, the cookie is returned only to the origin server (host-only). User agents reject cookies whose Domain attribute does not domain-match the request host, and many reject public-suffix domain values.
The Expires attribute specifies the maximum lifetime of a cookie as an RFC 1123-format date-time. User agents are not required to retain the cookie until that date; they may evict it earlier due to memory pressure or privacy concerns. Servers SHOULD use four-digit years to avoid two-digit year interpretation differences.
The HttpOnly attribute instructs the user agent to omit the cookie when providing access via non-HTTP APIs such as document.cookie in browsers. It is independent of the Secure attribute; a cookie may carry both.
The Max-Age attribute specifies cookie lifetime as a number of seconds. If both Max-Age and Expires are present, Max-Age takes precedence. A Max-Age value of zero or less causes immediate expiry. Some user agents do not support Max-Age and ignore it.
The Secure attribute restricts the cookie to 'secure' channels (typically HTTPS/TLS). It protects only the cookie's confidentiality in transit; an active network attacker can still overwrite Secure cookies from an insecure channel, undermining their integrity.
The permanent message header field registry is updated with four entries: Cookie (standard, Section 5.4) and Set-Cookie (standard, Section 5.2) are registered as current HTTP headers; Cookie2 and Set-Cookie2 are registered with status 'obsoleted', referencing RFC 2965.
Cookie and Set-Cookie headers are transmitted in cleartext unless sent over TLS. Servers SHOULD encrypt and sign cookie contents, and SHOULD use cookies only over secure channels, setting the Secure attribute on every cookie. Without the Secure attribute, an active network attacker can intercept cookies sent over HTTP and replay them against an HTTPS-only server.
Cookies provide weak confidentiality: they do not isolate by port (all ports on a host share cookies) or by scheme (ftp, gopher, etc. may access cookies set via http/https). Servers MUST NOT run mutually distrusting services on different ports of the same host while using cookies for security-sensitive state.
Cookies provide weak integrity: a sibling domain (e.g., foo.example.com) can set a Domain=example.com cookie that overwrites cookies set by bar.example.com, and an active network attacker can inject Set-Cookie headers via HTTP to poison an HTTPS server's cookie jar. The Path attribute provides no integrity protection. Servers SHOULD NOT run mutually distrusting services on different paths of the same host.
Cookies represent ambient authority: user agents automatically attach cookies to requests initiated by third parties, enabling cross-site request forgery (CSRF). Servers using cookies for authentication are vulnerable because a remote party can trigger authenticated requests without knowing cookie contents. Treating URLs as capabilities (storing secrets in URLs rather than cookies) can mitigate this.
The cookie storage model defines states: creation (name, value, creation-time, last-access-time set), persistent vs. session (persistent-flag based on Max-Age/Expires presence), host-only vs. domain (host-only-flag based on Domain attribute presence), secure-only, and http-only. Transitions include: receive → validate domain → check for existing matching cookie (same name+domain+path) → replace or insert. Cookies with http-only-flag set cannot be created or overwritten via non-HTTP APIs.
The Cookie request header is encoded as: `cookie-string = cookie-pair *( ";" SP cookie-pair )`, containing only name=value pairs with no attributes. The user agent MUST NOT attach more than one Cookie header field to an HTTP request.
The Set-Cookie header is encoded as: `set-cookie-string = cookie-pair *( ";" SP cookie-av )` where `cookie-pair = cookie-name "=" cookie-value`, cookie-name is an RFC 2616 token, and cookie-value is a sequence of US-ASCII octets excluding CTLs, whitespace, DQUOTE, comma, semicolon, and backslash (or the same enclosed in DQUOTE).