One document matched: draft-ietf-httpstate-cookie-06.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<!--<!DOCTYPE rfc SYSTEM "rfc2629.dtd">-->
<rfc ipr="pre5378Trust200902" docName="draft-ietf-httpstate-cookie-06"
category="std" obsoletes="2109">
<front>
<title abbrev="HTTP State Management Mechanism">
HTTP State Management Mechanism
</title>
<author initials="A." surname="Barth" fullname="Adam Barth">
<organization abbrev="U.C. Berkeley">
University of California, Berkeley
</organization>
<address>
<email>abarth@eecs.berkeley.edu</email>
<uri>http://www.adambarth.com/</uri>
</address>
</author>
<date month="April" year="2010"/>
<workgroup>httpstate</workgroup>
<abstract>
<t>This document defines the HTTP Cookie and Set-Cookie headers.
These headers can be used by HTTP servers to store state on HTTP user
agents, letting the servers maintain a stateful session over the
mostly stateless HTTP protocol. The cookie protocol has many
historical infelicities that degrade its security and privacy.
<list>
<t>NOTE: If you have suggestions for improving the draft, please send
email to http-state@ietf.org. Suggestions with test cases are
especially appreciated.</t>
</list>
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This document defines the HTTP Cookie and Set-Cookie header. Using
the Set-Cookie header, an HTTP server can store name/value pairs and
associated metadata (called cookies) at the user agent. When the user
agent makes subsequent requests to the server, the user agent uses the
metadata to determine whether to return the name/value pairs in the
Cookie header.</t>
<t>Although simple on its surface, the cookie protocol has a number of
complexities. For example, the server indicates a scope for each
cookie when sending them to the user agent. The scope indicates the
maximum amount of time the user agent should retain the cookie, to
which servers the user agent should return the cookie, and for which
protocols the cookie is applicable.</t>
<t>For historical reasons, the cookie protocol contains a number of
security and privacy infelicities. For example, a server can indicate
that a given cookie is intended for "secure" connections, but the
Secure attribute provides only confidentiality (not integrity) from
active network attackers. Similarly, cookies for a given host are
shared across all the ports on that host, even though the usual
"same-origin policy" used by web browsers isolates content retrieved
from different ports.</t>
</section>
<section anchor="general-nonsense" title="General Nonsense">
<section anchor="conformance-criteria" title="Conformance Criteria">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in document are to be
interpreted as described in <xref target="RFC2119"/>.</t>
<t>Requirements phrased in the imperative as part of algorithms (such
as "strip any leading space characters" or "return false and abort
these steps") are to be interpreted with the meaning of the key word
("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm.</t>
</section>
<section anchor="syntax-notation" title="Syntax Notation">
<t>This specification uses the Augmented Backus-Naur Form (ABNF)
notation of <xref target="RFC5234"/>.</t>
<t>The following core rules are included by reference, as defined in
<xref target="RFC5234"/>, Appendix B.1: ALPHA (letters), CR (carriage
return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE
(double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
OCTET (any 8-bit sequence of data), SP (space), HTAB (horizontal tab),
VCHAR (any visible [USASCII] character), and WSP (whitespace).</t>
<t>The OWS (optional whitespace) rule is used where zero or more
linear whitespace characters may appear. OWS SHOULD either not be
produced or be produced as a single SP character. Multiple OWS
characters that occur within field-content SHOULD be replaced with a
single SP before interpreting the field value or forwarding the
message downstream.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>The terms user agent, client, server, proxy, and origin server have
the same meaning as in the HTTP/1.1 specification (<xref
target="RFC2616"/>).</t>
<t>The terms request-host and request-URI refer to the values the user
agent would send to the server as, respectively, the host (but not
port) and abs_path portions of the absoluteURI (http_URL) of the HTTP
Request-Line.</t>
</section>
</section>
<section anchor="overview" title="Overview">
<t>We outline here a way for an origin server to send state
information to a user agent, and for the user agent to return the
state information to the origin server.</t>
<t>To initiate a session, the origin server includes a Set-Cookie header
in an HTTP response. (Note that "session" here does not refer to a
persistent network connection but to a logical session created from HTTP
requests and responses. The presence or absence of a persistent
connection should have no effect on the use of cookie-derived
sessions).</t>
<t>The user agent returns a Cookie request header to the origin server
if it chooses to continue a session. The Cookie header contains a number
of cookies the user agent received in previous Set-Cookie headers. The
origin server MAY ignore the Cookie header or use the header to
determine the current state of the session. The origin server MAY send
the user agent a Set-Cookie response header with the same or different
information, or it MAY send no Set-Cookie header at all.</t>
<t>Servers MAY return a Set-Cookie response header with any response.
User agents SHOULD send a Cookie request header, subject to other rules
detailed below, with every request.</t>
<t>An origin server MAY include multiple Set-Cookie header fields in a
single response. Note that an intervening gateway MUST NOT fold multiple
Set-Cookie header fields into a single header field.</t>
<t>If a server sends multiple responses containing Set-Cookie headers
concurrently to the user agent (e.g., when communicating with the user
agent over multiple sockets), these responses create a "race condition"
that can lead to unpredictable behavior.</t>
<section title="Examples">
<t>Using the cookie protocol, a server can send the user agent a short
string in an HTTP response that the user agent will return in future
HTTP requests. For example, the server can send the user agent a
"session identifier" named SID with the value 31d4d96e407aad42. The
user agent then returns the session identifier in subsequent
requests.</t>
<figure>
<artwork>
<![CDATA[
== Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42
== User Agent -> Server ==
Cookie: SID=31d4d96e407aad42
]]>
</artwork>
</figure>
<t>The server can alter the default scope of the cookie using the Path
and Domain attributes. For example, the server can instruct the user
agent to return the cookie to every path and every subdomain of
example.com.</t>
<figure>
<artwork>
<![CDATA[
== Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=.example.com
== User Agent -> Server ==
Cookie: SID=31d4d96e407aad42
]]>
</artwork>
</figure>
<t>The server can store multiple cookies in the user agent. For
example, the server can store a session identifier as well as the
user's preferred language by returning two Set-Cookie response
headers. Notice that the server uses the Secure and HttpOnly
attributes to provide additional security protections for the
more-sensitive session identifier.</t>
<figure>
<artwork>
<![CDATA[
== Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
Set-Cookie: lang=en-US; Path=/; Domain=.example.com
== User Agent -> Server ==
Cookie: SID=31d4d96e407aad42; lang=en-US
]]>
</artwork>
</figure>
<t>If the server wishes the user agent to persist the cookie over
multiple sessions, the server can specify a expiration date in the
Expires attribute. Note that the user agent might might delete the
cookie before the expiration date if the user agent's cookie store
exceeds its quota or if the user manually deletes the server's
cookie.</t>
<figure>
<artwork>
<![CDATA[
== Server -> User Agent ==
Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT
== User Agent -> Server ==
Cookie: lang=en-US
]]>
</artwork>
</figure>
<t>Finally, to remove a cookie, the server returns a Set-Cookie header
with an expiration date in the past. The server will be successful in
removing the cookie only if the Path and the Domain attribute in the
Set-Cookie header match the values used when the cookie was
created.</t>
<figure>
<artwork>
<![CDATA[
== Server -> User Agent ==
Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT
== User Agent -> Server ==
(No Cookie header)
]]>
</artwork>
</figure>
</section>
</section>
<section anchor="sane-profile" title="A Well-Behaved Profile">
<t>This section describes the syntax and semantics of a well-behaved
profile of the protocol. Servers SHOULD use the profile described in
this section, both to maximize interoperability with existing user
agents and because a future version of the cookie protocol could remove
support for some of the most esoteric aspects of the protocol. User
agents, however, MUST implement the full protocol to ensure
interoperability with servers making use of the full protocol.</t>
<section anchor="sane-set-cookie" title="Set-Cookie">
<t>The Set-Cookie header is used to send cookies from the server to
the user agent.</t>
<section anchor="sane-set-cookie-syntax" title="Syntax">
<t>Informally, the Set-Cookie response header comprises the token
Set-Cookie:, followed by a cookie. Each cookie begins with a
name-value-pair, followed by zero or more attribute-value pairs.
Servers SHOULD NOT send Set-Cookie headers that fail to conform to
the following grammar:</t>
<figure>
<artwork type="abnf">
<![CDATA[
set-cookie-header = "Set-Cookie:" OWS set-cookie-string OWS
set-cookie-string = cookie-pair *( ";" cookie-av )
cookie-pair = cookie-name "=" cookie-value
cookie-name = token
cookie-value = token
token = <token, as defined in RFC 2616>
cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av
expires-av = "Expires" "=" sane-cookie-date
sane-cookie-date = <rfc1123-date, as defined in RFC 2616>
max-age-av = "Max-Age" "=" 1*DIGIT
domain-av = "Domain" "=" domain-value
domain-value = token
path-av = "Path" "=" path-value
path-value = <abs_path, as defined in RFC 2616>
secure-av = "Secure"
httponly-av = "HttpOnly"
]]>
</artwork>
</figure>
<t>Servers SHOULD NOT include two attributes with the same name.</t>
<t>Servers SHOULD NOT include two Set-Cookie header fields in the
same response with the same cookie-name.</t>
<t>The cookie-value is opaque to the user agent and MAY be
anything the origin server chooses to send. "Opaque" implies that
the content is of interest and relevance only to the origin server.
The content is, in fact, readable by anyone who examines the
Set-Cookie header.</t>
<t>To maximize compatibility with user agents, servers that wish to
store non-ASCII data in a cookie-value SHOULD encode that data using
a printable ASCII encoding, such as base64.</t>
<t>NOTE: Some user agents represent dates using 32-bit integers.
Some of these user agents might contain bugs that cause them process
dates after the year 2038 incorrectly. Servers wishing to
interoperate with these user agents might wish to use dates before
2038.</t>
<t>NOTE: The syntax above allows whitespace between the attribute
and the U+003D ("=") character. Servers wishing to interoperate
with some legacy user agents might wish to omit this
whitespace.</t>
</section>
<section anchor="sane-set-cookie-semantics"
title="Semantics (Non-Normative)">
<t>This section describes a simplified semantics of the Set-Cookie
header. These semantics are detailed enough to be useful for
understanding the most common uses of the cookie protocol. The full
semantics are described in <xref target="cookie-protocol"
/>.</t>
<t>When the user agent receives a Set-Cookie header, the user agent
stores the cookie in its cookie store. When the user agent
subsequently makes an HTTP request, the user agent consults its
cookie store and includes the applicable, non-expired cookies in the
Cookie header.</t>
<t>If the cookie store already contains a cookie with the same
cookie-name, domain-value, and path-value, the existing cookie is
evicted from the cookie store and replaced with the new value.
Notice that servers can delete cookies by including an Expires
attribute with a value in the past.</t>
<t>Unless the cookie's attributes indicate otherwise, the cookie is
returned only to the origin server, and it expires at the end of the
current session (as defined by the user agent). User agents ignore
unrecognized cookie attributes.</t>
<section anchor="sane-expires" title="Expires">
<t>The Expires attribute indicates the maximum lifetime of the
cookie, represented as the date and time at which the cookie
expires. The user agent is not required to retain the cookie
until the specified date has passed. In fact, user agents often
evict cookies from the cookie store due to memory pressure or
privacy concerns.</t>
</section>
<section anchor="sane-max-age" title="Max-Age">
<t>The Max-Age attribute indicates the maximum lifetime of the
cookie, represented as the number of seconds until the cookie
expires. The user agent is not required to retain the cookie until
the specified date has passed. In fact, user agents often evict
cookies from the cookie store due to memory pressure or privacy
concerns.
<list>
<t>WARNING: Not all user agents support the Max-Age attribute.
User agents that do not support the Max-Age attribute will
retain the cookie for the current session only.</t>
</list>
</t>
<t>If a cookie has both the Max-Age and the Expires attribute, the
Max-Age attribute has precedence and controls the expiration date
of the cookie.</t>
</section>
<section anchor="sane-domain" title="Domain">
<t>The Domain attribute specifies those hosts for which the cookie
will be sent. For example, if the Domain attribute contains the
value ".example.com", the user agent will include the cookie in
the Cookie header when making HTTP requests to example.com,
www.example.com, and www.corp.example.com. (Note that a leading
U+002E ("."), if present, is ignored.) If the server omits the
Domain attribute, the user agent will return the cookie only to
the origin server.
<list>
<t>WARNING: Some legacy user agents treat an absent Domain
attribute as if the Domain attribute were present and contained
the current host name. For example, if example.com returns a
Set-Cookie header without a Domain attribute, these user agents
will send the cookie to www.example.com.</t>
</list>
</t>
<t>The user agent will reject cookies (refuse to store them in the
cookie store) unless the Domain attribute specifies a scope for
the cookie that would include the origin server. For example, the
user agent will accept a Domain attribute of ".example.com" or of
".foo.example.com" from foo.example.com, but the user agent will
not accept a Domain attribute of ".bar.example.com" or of
".baz.foo.example.com".</t>
<t>NOTE: For security reasons, some user agents are configured to
reject Domain attributes that do not correspond to a "registry
controlled" domain (or a subdomain of a registry controlled
domain). For example, some user agents will reject Domain
attributes of ".com" or ".co.uk".</t>
</section>
<section anchor="sane-path" title="Path">
<t>The Path attribute limits the scope of the cookie to a set of
paths. When a cookie has a Path attribute, the user agent will
include the cookie in an HTTP request only if the path portion of
the Request-URI matches (or is a subdirectory of) the cookie's
Path attribute, where the U+002F ("/") character is interpreted as a
directory separator. If the server omits the Path attribute, the
user agent will use the directory of the Request-URI's path
component as the default value.</t>
<t>Although seemingly useful for isolating cookies between
different paths within a given domain, the Path attribute cannot
be relied upon for security for two reasons: First, user agents do
not prevent one path from overwriting the cookies for another
path. For example, if a response to a request for /foo/bar.html
attempts to set a cookie with a Path attribute of "/baz" the user
agent will store that cookie in the cookie store. Second, the
"same-origin" policy implemented by many user agents does not
isolate different paths within an origin. For example,
/foo/bar.html can read cookies with a Path attribute of "/baz"
because they are within the "same origin".</t>
</section>
<section anchor="sane-secure" title="Secure">
<t>The Secure attribute limits the scope of the cookie to "secure"
channels (where "secure" is defined by the user agent). When a
cookie has the Secure attribute, the user agent will include the
cookie in an HTTP request only if the request is transmitted over
a secure channel (typically TLS <xref target="RFC5246"/>).</t>
<t>Although seemingly useful for protecting cookies from active
network attackers, the Secure attribute protects only the cookie's
confidentiality. An active network attacker can overwrite Secure
cookies from an insecure channel, disrupting the integrity of the
cookies.</t>
</section>
<section anchor="sane-httponly" title="HttpOnly">
<t>The HttpOnly attribute limits the scope of the cookie to HTTP
requests. In particular, the attribute instructs the user agent to
omit the cookie when providing access to its cookie store via
"non-HTTP" APIs (as defined by the user agent).</t>
</section>
</section>
</section>
<section anchor="sane-cookie" title="Cookie">
<section anchor="sane-cookie-syntax" title="Syntax">
<t>The user agent returns stored cookies to the origin server in
the Cookie header. If the server conforms to the requirements in
this section, the requirements in the next section will cause the
user agent to return a Cookie header that conforms to the following
grammar:</t>
<figure>
<artwork type="abnf">
<![CDATA[
cookie-header = "Cookie:" OWS cookie-string OWS
cookie-string = cookie-pair *( ";" cookie-pair )
]]>
</artwork>
</figure>
</section>
<section anchor="sane-cookie-semantics" title="Semantics">
<t>Each cookie-pair represents a cookie stored by the user
agent. The cookie-name and the cookie-value are returned verbatim
from the corresponding parts of the Set-Cookie header.</t>
<t>Notice that the cookie attributes are not returned. In
particular, the server cannot determine from the Cookie header alone
when a cookie will expire, for which domains the cookie is valid,
for which paths the cookie is valid, or whether the cookie was set
with the Secure or HttpOnly attributes.</t>
<t>The semantics of individual cookies in the Cookie header is not
defined by this document. Servers are expected to imbue these
cookies with server-specific semantics.</t>
<t>Although cookies are serialized linearly in the Cookie header,
servers SHOULD NOT rely upon the serialization order. In particular,
if the Cookie header contains two cookies with the same name,
servers SHOULD NOT rely upon the order in which these cookies appear
in the header.</t>
</section>
</section>
</section>
<section anchor="cookie-protocol" title="The Cookie Protocol">
<t>For historical reasons, the full cookie protocol contains a number of
exotic quirks. This section is intended to specify the cookie protocol
in enough detail to enable a user agent that implements the protocol
precisely as specified to interoperate with existing servers.</t>
<t>Conformance requirements phrased as algorithms or specific steps
may be implemented in any manner, so long as the end result is
equivalent. (In particular, the algorithms defined in this
specification are intended to be easy to follow, and not intended to
be performant.)</t>
<section anchor="algorithms" title="Algorithms">
<t>This section defines a number of algorithms used by the cookie
protocol.</t>
<section anchor="cookie-date" title="Dates">
<t>The user agent MUST use the following algorithm to *parse a
cookie-date*:
<list style="numbers">
<t>Using the grammar below, divide the cookie-date into
date-tokens.
<figure>
<artwork type="abnf">
<![CDATA[
cookie-date = *delimiter date-token-list *delimiter
date-token-list = date-token *( 1*delimiter date-token )
delimiter = %x09 / %x20 / %x21 / %x22 / %x23 / %x24 /
%x25 / %x26 / %x27 / %x28 / %x29 / %x2A /
%x2B / %x2C / %x2D / %x2E / %x2F / %x3B /
%x3C / %x3D / %x3E / %x3F / %x40 / %x5B /
%x5C / %x5D / %x5E / %x5F / %x60 / %x7B /
%x7C / %x7D / %x7E
date-token = day-of-month / month / year / time / mystery
day-of-month = 2DIGIT / DIGIT
month = "jan" [ mystery ] / "feb" [ mystery ] /
"mar" [ mystery ] / "apr" [ mystery ] /
"may" [ mystery ] / "jun" [ mystery ] /
"jul" [ mystery ] / "aug" [ mystery ] /
"sep" [ mystery ] / "oct" [ mystery ] /
"nov" [ mystery ] / "dec" [ mystery ]
year = 5DIGIT / 4DIGIT / 3DIGIT / 2DIGIT / DIGIT
time = time-field ":" time-field ":" time-field
time-field = 2DIGIT / DIGIT
mystery = <anything except a delimiter>
]]>
</artwork>
</figure>
</t>
<t>Process each date-token sequentially in the order the
date-tokens appear in the cookie-date:
<list style="numbers">
<t>If the found-day-of-month flag is not set and the date-token
matches the day-of-month production, set the found-day-of-month
flag and set the day-of-month-value to the number denoted by the
date-token. Skip the remaining sub-steps and continue to the
next date-token.</t>
<t>If the found-month flag is not set and the date-token matches
the month production, set the found-month flag and set the
month-value to the month denoted by the date-token. Skip the
remaining sub-steps and continue to the next date-token.</t>
<t>If the found-year flag is not set and the date-token matches
the year production, set the found-year flag and set the
year-value to the number denoted by the date-token. Skip the
remaining sub-steps and continue to the next date-token.</t>
<t>If the found-time flag is not set and the token matches the
time production, set the found-time flag and set the hour-value,
minute-value, and second-value to the numbers denoted by the
digits in the date-token, respectively. Skip the remaining
sub-steps and continue to the next date-token.</t>
</list>
</t>
<t>Abort these steps and *fail to parse* if
<list style="symbols">
<t>at least one of the found-day-of-month, found-month,
found-year, or found-time flags is not set,</t>
<t>the day-of-month-value is less than 1 or greater than 31,</t>
<t>the year-value is less than 1601 or greater than 30827,</t>
<t>the hour-value is greater than 23,</t>
<t>the minute-value is greater than 59, or</t>
<t>the second-value is greater than 59.</t>
</list>
</t>
<t>If the year-value is greater than 68 and less than 100,
increment the year-value by 1900.</t>
<t>If the year-value is greater than or equal to 0 and less than
69, increment the year-value by 2000.</t>
<t>Let the parsed-cookie-date be the date whose day-of-month,
month, year, hour, minute, and second (in GMT) are the
day-of-month-value, the month-value, the year-value, the
hour-value, the minute-value, and the second-value,
respectively.</t>
<t>Return the parsed-cookie-date as the result of this
algorithm.</t>
</list>
</t>
</section>
<section anchor="cookie-domain" title="Domains">
<t>A *canonicalized* host-name is the host-name converted to
lower case and expressed in punycode <xref target="RFC3492"/>.</t>
<t>A request-host *domain-matches* a cookie-domain if at least one
of the following conditions hold:
<list style="symbols">
<t>The cookie-domain and the canonicalized request-host are
identical.</t>
<t>All of the following conditions hold:
<list style="symbols">
<t>The cookie-domain is a suffix of the canonicalized
request-host.</t>
<t>The last character of the canonicalized request-host that is
not included in the cookie-domain is a U+002E (".")
character.</t>
<t>The request-host is a host name (i.e., not an IP address).</t>
</list>
</t>
</list>
</t>
</section>
<section anchor="cookie-path" title="Paths">
<t>The user agent MUST use the following algorithm to compute the
*default-path* of a cookie:
<list style="numbers">
<t>Let uri-path be the path portion of the Request-URI.</t>
<t>If the first character of the uri-path is not a U+002F ("/")
character, output U+002F ("/") and skip the remaining steps.</t>
<t>If the uri-path contains only a single U+002F ("/") character,
output U+002F ("/") and skip the remaining steps.</t>
<t>Output the characters of the uri-path from the first character
up to, but not including, the right-most U+002F ("/").</t>
</list>
</t>
<t>A request-path *path-matches* a cookie-path if at least one of
the following conditions hold:
<list style="symbols">
<t>The cookie-path and the request-path are identical.</t>
<t>The cookie-path is a prefix of the request-path and the last
character of the cookie-path is U+002F ("/").</t>
<t>The cookie-path is a prefix of the request-path and the first
character of the request-path that is not included in the
cookie-path is a U+002F ("/") character.</t>
</list>
</t>
</section>
</section>
<section anchor="set-cookie" title="The Set-Cookie Header">
<t>When a user agent receives a Set-Cookie header in an HTTP
response, the user agent *receives a set-cookie-string*
consisting of the value of the header.</t>
<t>A user agent MUST use the following algorithm to parse
set-cookie-strings:
<list style="numbers">
<t>If the set-cookie-string is empty or consists entirely of WSP
characters, the user agent MAY ignore the set-cookie-string
entirely.</t>
<t>If the set-cookie-string contains a U+003B (";") character:
<list style="empty">
<t>The name-value-pair string consists of the characters up to,
but not including, the first U+003B (";"), and the
unparsed-attributes consist of the remainder of the
set-cookie-string (including the U+003B (";") in question).</t>
</list>
Otherwise:
<list style="empty">
<t>The name-value-pair string consists of all the characters
contained in the set-cookie-string, and the unparsed-attributes
is the empty string.</t>
</list>
</t>
<t>If the name-value-pair string lacks a U+003D ("=") character,
ignore the set-cookie-string entirely.</t>
<t>If the first character of the name-value-pair string is U+003D
("="), ignore the set-cookie-string entirely.</t>
<t>The (necessarily non-empty) name string consists of the
characters up to, but not including, the first U+003D ("=")
character, and the (possibly empty) value string consists of the
characters after the first U+003D ("=") character.</t>
<t>Remove any leading or trailing WSP characters from the name
string and the value string.</t>
<t>The cookie-name is the name string, and the cookie-value is the
value string.</t>
</list>
</t>
<t>The user agent MUST use the following algorithm to parse the
unparsed-attributes:
<list style="numbers">
<t>If the unparsed-attributes string is empty, skip the rest of
these steps.</t>
<t>Consume the first character of the unparsed-attributes (which
will be a U+003B (";") character).</t>
<t>If the remaining unparsed-attributes contains a U+003B (";")
character:
<list style="empty">
<t>Consume the characters of the unparsed-attributes up to, but
not including, the first U+003B (";") character.</t>
</list>
Otherwise:
<list style="empty">
<t>Consume the remainder of the unparsed-attributes.</t>
</list>
Let the cookie-av string be the characters consumed in this
step.</t>
<t>If the cookie-av string contains a U+003D ("=") character:
<list style="empty">
<t>The (possibly empty) attribute-name string consists of the
characters up to, but not including, the first U+003D ("=")
character, and the (possibly empty) attribute-value string
consists of the characters after the first U+003D ("=")
character.</t>
</list>
Otherwise:
<list style="empty">
<t>The attribute-name string consists of the entire cookie-av
string, and the attribute-value string is empty. (Note that this
step differs from the analogous step when parsing the
name-value-pair string.)</t>
</list>
</t>
<t>Remove any leading or trailing WSP characters from the
attribute-name string and the attribute-value string.</t>
<t>Process the attribute-name and attribute-value according to the
requirements in the following subsections.</t>
<t>Return to Step 1.</t>
</list>
</t>
<t>When the user agent finishes parsing the set-cookie-string,
the user agent *receives a cookie* from the Request-URI with name
cookie-name, value cookie-value, and attributes
cookie-attribute-list.</t>
<section anchor="max-age-attribute" title="The Max-Age Attribute">
<t>If the attribute-name case-insensitively matches the string
"Max-Age", the user agent MUST process the cookie-av as follows.</t>
<t>If the first character of the attribute-value is not a DIGIT or a
"-" character, ignore the cookie-av.</t>
<t>If the remainder of attribute-value contains a non-DIGIT
character, ignore the cookie-av.</t>
<t>Let delta-seconds be the attribute-value converted to an
integer.</t>
<t>If delta-seconds is less than or equal to zero (0), let
expiry-time be the current date and time. Otherwise, let the
expiry-time be the current date and time plus delta-seconds
seconds.</t>
<t>Append an attribute to the cookie-attribute-list with an
attribute-name of Max-Age and an attribute-value of expiry-time.</t>
</section>
<section anchor="expires-attribute" title="The Expires Attribute">
<t>If the attribute-name case-insensitively matches the string
"Expires", the user agent MUST process the cookie-av as follows.</t>
<t>Let the parsed-cookie-date be the result of parsing the
attribute-value as cookie-date.</t>
<t>If the attribute-value failed to parse as a cookie date, ignore
the cookie-av.</t>
<t>If the user agent received the set-cookie-string from an HTTP
response that contains a Date header field and the contents of the
last Date header field successfully parse as a cookie-date:
<list style="empty">
<t>Let server-date be the date obtained by parsing the contents of
the last Date header field as a cookie-date.</t>
<t>Let delta-seconds be the number of seconds between the
server-date and the parsed-cookie-date (i.e., parsed-cookie-date
- server-date).</t>
<t>Let the expiry-time be the current date and time plus
delta-seconds seconds.</t>
</list>
Otherwise:
<list style="empty">
<t>Let the expiry-time be the parsed-cookie-date.</t>
</list>
</t>
<t>If the expiry-time is later than the last date the user agent
can represent, the user agent MAY replace the expiry-time with the
last representable date.</t>
<t>If the expiry-time is earlier than the first date the user agent
can represent, the user agent MAY replace the expiry-time with the
first representable date.</t>
<t>Append an attribute to the cookie-attribute-list with an
attribute-name of Expires and an attribute-value of expiry-time.</t>
</section>
<section anchor="domain-attribute" title="The Domain Attribute">
<t>If the attribute-name case-insensitively matches the string
"Domain", the user agent MUST process the cookie-av as follows.</t>
<t>If the attribute-value is empty, the behavior is undefined.
However, user agent SHOULD ignore the cookie-av entirely.</t>
<t>If the first character of the attribute-value string is U+002E
("."):
<list style="empty">
<t>Let cookie-domain be the attribute-value without the leading
U+002E (".") character.</t>
</list>
Otherwise:
<list style="empty">
<t>Let cookie-domain be the entire attribute-value.</t>
</list>
</t>
<t>Convert the cookie-domain to lower case.</t>
<t>Append an attribute to the cookie-attribute-list with an
attribute-name of Domain and an attribute-value of
cookie-domain.</t>
</section>
<section anchor="path-attribute" title="The Path Attribute">
<t>If the attribute-name case-insensitively matches the string
"Path", the user agent MUST process the cookie-av as follows.</t>
<t>If the attribute-value is empty or if the first character of the
attribute-value is not U+002F ("/"):
<list style="empty">
<t>Let cookie-path be the default-path.</t>
</list>
Otherwise:
<list style="empty">
<t>Let cookie-path be the attribute-value.</t>
</list>
</t>
<t>Append an attribute to the cookie-attribute-list with an
attribute-name of Path and an attribute-value of cookie-path.</t>
</section>
<section anchor="secure-attribute" title="The Secure Attribute">
<t>If the attribute-name case-insensitively matches the string
"Secure", the user agent MUST append an attribute to the
cookie-attribute-list with an attribute-name of Secure and an empty
attribute-value.</t>
</section>
<section anchor="httponly-attribute" title="The HttpOnly Attribute">
<t>If the attribute-name case-insensitively matches the string
"HttpOnly", the user agent MUST append an attribute to the
cookie-attribute-list with an attribute-name of HttpOnly and an
empty attribute-value.</t>
</section>
</section>
<section anchor="storage-model" title="Storage Model">
<t>When the user agent receives a cookie, the user agent SHOULD
record the cookie in its cookie store as follows.</t>
<t>A user agent MAY ignore a received cookie in its entirety if the
user agent is configured to block receiving cookies. For example, the
user agent might wish to block receiving cookies from "third-party"
responses.</t>
<t>The user agent stores the following fields about each cookie: name,
value, expiry-time, domain, path, creation-time, last-access-time,
persistent-flag, host-only-flag, secure-only-flag, and
http-only-flag.</t>
<t>When the user agent receives a cookie from a Request-URI with name
cookie-name, value cookie-value, and attributes cookie-attribute-list,
the user agent MUST process the cookie as follows:
<list style="numbers">
<t>Create a new cookie with name cookie-name, value cookie-value.
Set the creation-time and the last-access-time to the current date
and time.</t>
<t>If the cookie-attribute-list contains an attribute with an
attribute-name of "Max-Age":
<list style="empty">
<t>Set the cookie's persistent-flag to true.</t>
<t>Set the cookie's expiry-time to attribute-value of the last
attribute in the cookie-attribute-list with an attribute-name of
"Max-Age".</t>
</list>
Otherwise, if the cookie-attribute-list contains an attribute with an
attribute-name of "Expires" (and does not contain an attribute with
an attribute-name of "Max-Age"):
<list style="empty">
<t>Set the cookie's persistent-flag to true.</t>
<t>Set the cookie's expiry-time to attribute-value of the last
attribute in the cookie-attribute-list with an attribute-name of
"Expires".</t>
</list>
Otherwise:
<list style="empty">
<t>Set the cookie's persistent-flag to false.</t>
<t>Set the cookie's expiry-time to the latest representable
date.</t>
</list>
</t>
<t>If the cookie-attribute-list contains an attribute with an
attribute-name of "Domain":
<list style="empty">
<t>Let the domain-attribute be the attribute-value of the last
attribute in the cookie-attribute-list with an attribute-name of
"Domain".</t>
</list>
Otherwise:
<list style="empty">
<t>Let the domain-attribute be the empty string.</t>
</list>
</t>
<t>If the user agent is configured to use a "public suffix" list
and the domain-attribute is a public suffix:
<list style="empty">
<t>If the domain-attribute is identical to the canonicalized
Request-URI's host:
<list style="empty">
<t>Let the domain-attribute be the empty string.</t>
</list>
Otherwise:
<list style="empty">
<t>Ignore the cookie entirely and abort these steps</t>
</list>
</t>
<t>NOTE: A "public suffix" is a domain that is controlled by a
public registry, such as "com", "co.uk", and "pvt.k12.wy.us".
This step is essential for preventing attacker.com from
disrupting the integrity of example.com by setting a cookie with
a Domain attribute of "com". Unfortunately, the set of public
suffixes (also known as "registry controlled domains") changes
over time. If feasible, user agents SHOULD use an up-to-date
public suffix list, such as the one maintained by the Mozilla
project at http://publicsuffix.org/.</t>
</list>
</t>
<t>If the domain-attribute is non-empty:
<list style="empty">
<t>If the Request-URI's host does not domain-match the
domain-attribute, ignore the cookie entirely and abort these
steps.</t>
<t>Set the cookie's host-only-flag to false.</t>
<t>Set the cookie's domain to the domain-attribute.</t>
</list>
Otherwise:
<list style="empty">
<t>Set the cookie's host-only-flag to true.</t>
<t>Set the cookie's domain to the host of the Request-URI.</t>
</list>
</t>
<t>If the cookie-attribute-list contains an attribute with an
attribute-name of "Path", set the cookie's path to attribute-value
of the last attribute in the cookie-attribute-list with an
attribute-name of "Path". Otherwise, set cookie's path to the
default-path of the Request-URI.</t>
<t>If the cookie-attribute-list contains an attribute with an
attribute-name of "Secure", set the cookie's secure-only-flag to
true. Otherwise, set cookie's secure-only-flag to false.</t>
<t>If the cookie-attribute-list contains an attribute with an
attribute-name of "HttpOnly", set the cookie's http-only-flag to
true. Otherwise, set cookie's http-only-flag to false.</t>
<t>If the cookie's name and value are both empty, abort these
steps and ignore the cookie entirely.</t>
<t>If the cookie's expiry-time is not in the future, abort these
steps and ignore the cookie entirely.</t>
<t>If the cookie was received from a non-HTTP context and the
cookie's http-only-flag is set, abort these steps and ignore the
cookie entirely.</t>
<t>If the cookie store contains a cookie with the same name, domain,
and path as the newly created cookie:
<list>
<t>Let old-cookie be the existing cookie with the same name,
domain, and path as the newly created cookie. (Notice that this
algorithm maintains the invariant that there is at most one such
cookie.)</t>
<t>If the newly created cookie was received from an non-HTTP
context and the old-cookie's host-only-flag is set, abort these
steps and ignore the newly created cookie entirely.</t>
<t>Update the creation-time of the newly created cookie to match
the creation-time of the old-cookie.</t>
<t>Remove the old-cookie from the cookie store.</t>
</list>
</t>
<t>Insert the newly created cookie into the cookie store.</t>
</list>
</t>
<t>The user agent MUST evict a cookie from the cookie store if, at any
time, a cookie exists in the cookie store with an expiry date in the
past.</t>
<t>The user agent MAY evict a cookie from the cookie store if the
number of cookies sharing a domain field exceeds some predetermined
upper bound (such as 50 cookies).</t>
<t>The user agent MAY evict a cookie from the cookie store if the
cookie store exceeds some predetermined upper bound (such as 3000
cookies).</t>
<t>When the user agent evicts a cookie from the cookie store, the
user agent MUST evict cookies in the following priority order:
<list style="numbers">
<t>Cookies with an expiry date in the past.</t>
<t>Cookies that share a domain field with more than a predetermined
number of other cookies.</t>
<t>All cookies.</t>
</list>
</t>
<t>If two cookies have the same removal priority, the user agent
MUST evict the cookie with the least recent last-access date
first.</t>
<t>When "the current session is over" (as defined by the user agent),
the user agent MUST remove from the cookie store all cookies with the
persistent-flag set to false.</t>
</section>
<section anchor="cookie" title="The Cookie Header">
<t>When the user agent generates an HTTP request, the user agent
SHOULD attach exactly one HTTP header named Cookie if the
cookie-string (defined below) for the Request-URI is non-empty.</t>
<t>A user agent MAY omit the Cookie header in its entirety if the
user agent is configured to block sending cookies. For example, the
user agent might wish to block sending cookies during "third-party"
requests.</t>
<t>The user agent MUST use the following algorithm to compute the
cookie-string from a cookie store and a Request-URI:
<list style="numbers">
<t>Let cookie-list be the set of cookies from the cookie store
that meet all of the following requirements:
<list style="symbols">
<t>Let request-host be the Request-URI's host. Either:
<list style="empty">
<t>The cookie's host-only-flag is true and the canonicalized
request-host is identical to the cookie's domain.</t>
</list>
Or:
<list style="empty">
<t>The cookie's host-only-flag is false and the request-host
domain-matches cookie's domain.</t>
</list>
</t>
<t>The Request-URI's path patch-matches cookie's path.</t>
<t>If the cookie's secure-only-flag is true, then the
Request-URI's scheme must denote a "secure" protocol (as defined
by the user agent).
<list style="empty">
<t>NOTE: The notion of a "secure" protocol is not defined by
this document. Typically, user agents consider a protocol
secure if the protocol makes use of transport-layer security,
such as TLS. For example, most user agents consider "https"
to be a scheme that denotes a secure protocol.</t>
</list>
</t>
<t>If the cookie's http-only-flag is true, then exclude the
cookie unless the cookie-string is being generated for an
"HTTP" API (as defined by the user agent).</t>
</list>
</t>
<t>The user agent SHOULD sort the cookie-list in the following
order:
<list style="symbols">
<t>Cookies with longer paths are listed before cookies
with shorter paths.</t>
<t>Among cookies that have equal length path fields, cookies
with earlier creation-times are listed before cookies with later
creation-times.</t>
</list>
<list style="empty">
<t>NOTE: Not all user agents sort the cookie-list in this order,
but this order reflects common practice when this document was
written. The specific ordering might not be optimal in every
metric, but using the consensus ordering is a relatively low cost
way to improve interoperability between user agents.</t>
</list>
</t>
<t>Update the last-access-time of each cookie in the cookie-list
to the current date and time.</t>
<t>Serialize the cookie-list into a cookie-string by processing each
cookie in the cookie-list in order:
<list style="numbers">
<t>Output the cookie's name, the U+003D ("=") character, and the
cookie's value.</t>
<t>If there is an unprocessed cookie in the cookie-list, output
the characters U+003B and U+0020 ("; ").</t>
</list>
</t>
</list>
Note: Despite its name, the cookie-string is actually a sequence of
octets, not a sequence of characters. To convert the cookie-string
into a sequence of characters (e.g., for presentation to the user),
the user agent SHOULD use the UTF-8 character encoding
<xref target="RFC3629" />.</t>
</section>
</section>
<section anchor="implementation-considerations"
title="Implementation Considerations">
<section anchor="implementation-limits" title="Limits">
<t>Practical user agent implementations have limits on the number
and size of cookies that they can store. General-use user agents
SHOULD provide each of the following minimum capabilities:
<list style="symbols">
<t>At least 4096 bytes per cookie (as measured by the sum of the
length of the cookie's name, value, and attributes).</t>
<t>At least 50 cookies per domain.</t>
<t>At least 3000 cookies total.</t>
</list>
</t>
<t>Servers SHOULD use as few and as small cookies as possible to avoid
reaching these implementation limits and to avoid network latency due
to the Cookie header being included in every request.</t>
<t>Servers should gracefully degrade if the user agent fails to return
one or more cookies in the Cookie header because the user agent might
evict any cookie at any time on orders from the user.</t>
</section>
<section anchor="implementation-apis"
title="Application Programmer Interfaces">
<t>One reason the cookie protocol uses such an esoteric syntax is
because many platforms (both in servers and user agents) provide
string-based application programmer interfaces (APIs), requiring
application-layer programmers to generate and parse the syntax used by
the cookie protocol.</t>
<t>Instead of providing string-based APIs to the cookie protocols,
implementations would be well-served by providing more semantic APIs.
It is beyond the scope of this document to recommend specific API
designs, but there are clear benefits to accepting a abstract "Date"
object instead of a serialized date string.</t>
</section>
</section>
<section anchor="privacy-considerations"
title="Privacy Considerations">
<t>The cookie protocol is often criticized for letting servers track
users. For example, a number of "web analytics" companies use cookies
to recognize when a user returns to a web site or visits another web
site. Although cookies are not the only mechanism servers can use to
track users across HTTP requests, cookies facilitate tracking because
they are persistent across user agent sessions and can be shared
between host names.</t>
<section anchor="third-party-cookies" title="Third-Party Cookies">
<t>Particularly worrisome are so-called "third-party" cookies. In
rendering an HTML document, a user agent often requests resources
from other servers (such as advertising networks). These third-party
servers can use the cookie protocol to track the user even if the
user never visits the server directly.</t>
<t>Some user agents restrict how third-party cookies behave. For
example, some user agents refuse to send the Cookie header in
third-party requests. Other user agents refuse to process the
Set-Cookie header in responses to third-party requests. Among user
agents, there is a wide variety of third-party cookie policies. This
document grants user agents wide latitude to experiment with
third-party cookie policies that balance the privacy and
compatibility needs of their users. However, this document does not
endorse any particular third-party cookie policy.</t>
<t>Third-party cookie blocking policies are often ineffective at
achieving their privacy goals if servers attempt to work around
their restrictions to track users. In particular, two collaborating
servers can often track users without using cookies at all.</t>
</section>
<section anchor="user-controls" title="User Controls">
<t>User agents SHOULD provide users with a mechanism for managing
the cookies stored in the cookie store. For example, a user agent
might let users delete all cookies received during a specified time
period or all the cookies related to a particular domain. In
addition, many user agent include a user interface element that lets
users examine the cookies stored in the cookie store.</t>
<t>User agents SHOULD provide users with a mechanism for disabling
cookies. When cookies are disabled, the user agent MUST NOT include
a Cookie header in outbound HTTP requests and the user agent MUST
NOT process Set-Cookie headers in inbound HTTP responses.</t>
<t>Some user agents provide users the option of preventing
persistent storage of cookies across sessions. When configured
thusly, user agents MUST treat all received cookies as if the
persistent-flag were set to false.</t>
<t>Some user agents provide users with the ability to approve
individual writes to the cookie store. In many common usage
scenarios, these controls generate a large number of prompts.
However, some privacy-conscious users find these controls useful
nonetheless.</t>
</section>
</section>
<section anchor="security-considerations"
title="Security Considerations">
<section anchor="section-overview" title="Overview">
<t>The cookie protocol has a number of security and privacy
pitfalls.</t>
<t>In particular, cookies encourage developers to rely on ambient
authority for authentication, often creating vulnerabilities such as
cross-site request forgery. When storing session identifiers in
cookies, developers often create session fixation
vulnerabilities.</t>
<t>Transport-layer encryption, such as that employed in HTTPS, is
insufficient to prevent a network attacker from obtaining or altering a
victim's cookies because the cookie protocol itself has various
vulnerabilities (see "Weak Confidentiality" and "Weak Integrity",
below). In addition, by default, the cookie protocol does not provide
confidentiality or integrity from network attackers, even when used in
conjunction with HTTPS.</t>
</section>
<section anchor="ambient-authority" title="Ambient Authority">
<t>A server that uses cookies to authenticate users can suffer
security vulnerabilities because some user agents let remote parties
issue HTTP requests from the user agent (e.g., via HTTP redirects and
HTML forms). When issuing those requests, user agent attaches cookies
even if the entity does not know the contents of the cookies, possibly
letting the remote entity exercise authority at an unwary server.</t>
<t>Although this security concern goes by a number of names (e.g.,
cross-site request forgery, confused deputy), the issue stems from
cookies being a form of ambient authority. Cookies encourage server
operators to separate designation (in the form of URLs) from
authorization (in the form of cookies). Consequently, the user agent
might supply the authorization for a resource designated by the
attacker, possibly causing the server or its clients to undertake
actions designated by the attacker as though they were authorized by
the user.</t>
<t>Instead of using cookies for authorization, server operators might
wish to consider entangling designation and authorization by treating
URLs as capabilities. Instead of storing secrets in cookies, this
approach stores secrets in URLs, requiring the remote entity to supply
the secret itself. Although this approach is not a panacea, judicious
use of these principles can lead to more robust security.</t>
</section>
<section anchor="clear-text" title="Clear Text">
<t>Unless sent over a secure channel (such as TLS), the information in
the Set-Cookie and Cookie headers is transmitted in the clear.
<list style="numbers">
<t>All sensitive information conveyed in these headers is exposed to
an eavesdropper.</t>
<t>A malicious intermediary could alter the headers as they travel
in either direction, with unpredictable results.</t>
<t>A malicious client could alter the Cookie header before
transmission, with unpredictable results.</t>
</list>
</t>
<t>Servers SHOULD encrypt and sign the contents of cookies when
transmitting them to the user agent (even when sending the cookies
over a secure channel). However, encrypting and signing cookie
contents does not prevent an attacker from transplanting a cookie from
one user agent to another or from replaying the cookie at a later
time.</t>
<t>In addition to encrypting and signing the contents of every
cookie, servers that require a higher level of security SHOULD use the
cookie protocol only over a secure channel. When using the cookie
protocol over a secure channel, servers SHOULD set the Secure
attribute in every cookie. If a server does not set the Secure
attribute, the protection provided by the secure channel will be
largely moot.</t>
</section>
<section anchor="session-identifiers" title="Session Identifiers">
<t>Instead of storing session information directly in a cookie (where
it might be exposed to or replayed by an attacker), servers commonly
store a nonce (or "session identifier") in a cookie. When the server
receives an HTTP request with a nonce, the server can look up state
information associated with the cookie using the nonce as a key.</t>
<t>Using session identifier cookies limits the damage an attacker can
cause if the attacker learns the contents of a cookie because the
nonce is useful only for interacting with the server (unlike non-nonce
cookie content, which might itself be sensitive). Furthermore, using a
single nonce prevents an attacker from "splicing" together cookie
content from two interactions with the server, which could cause the
server to behave unexpectedly.</t>
<t>Using session identifiers is not without risk. For example, the
server SHOULD take care to avoid "session fixation" vulnerabilities. A
session fixation attack proceeds in three steps. First, the
attacker transplants a session identifier from his or her user agent
to the victim's user agent. Second, the victim uses that session
identifier to interact with the server, possibly imbuing the session
identifier with the user's credentials or confidential information.
Third, the attacker uses the session identifier to interact with
server directly, possibly obtaining the user's authority or
confidential information.</t>
</section>
<section anchor="weak-confidentiality" title="Weak Confidentiality">
<t>Cookies do not provide isolation by port. If a cookie is readable
by a service running on one port, the cookie is also readable by a
service running on another port of the same server. If a cookie is
writable by a service on one port, the cookie is also writable by a
service running on another port of the same server. For this reason,
servers SHOULD NOT both run mutually distrusting services on different
ports of the same host and use cookies to store security-sensitive
information.</t>
<t>Cookies do not provide isolation by scheme. Although most commonly
used with the http and https schemes, the cookies for a given host
might also available to other schemes, such as ftp and gopher.
Although this lack of isolation by scheme is most apparent in via
non-HTTP APIs that permit access to cookies (e.g., HTML's
document.cookie API), the lack of isolation by scheme is actually
present in the cookie protocol itself (e.g., consider retrieving a URI
with the gopher scheme via HTTP).</t>
<t>Cookies do not always provide isolation by path. Although the
network-level protocol does not send cookie stored for one path to
another, some user agents expose cookies via non-HTTP APIs, such as
HTML's document.cookie API. Because some of these user agents (e.g.,
web browsers) do not isolate resources received from different paths,
a resource retrieved from one path might be able to access cookies
stored for another path.</t>
</section>
<section anchor="weak-integrity" title="Weak Integrity">
<t>Cookies do not provide integrity guarantees for sibling domains
(and their subdomains). For example, consider foo.example.com and
bar.example.com. The foo.example.com server can set a cookie with a
Domain attribute of ".example.com" (possibly overwriting an existing
".example.com" cookie set by bar.example.com), and the user agent will
include that cookie in HTTP requests to bar.example.com. In the worst
case, bar.example.com will be unable to distinguish this cookie from a
cookie it set itself. The foo.example.com server might be able to
leverage this ability to mount an attack against bar.example.com.</t>
<t>Even though the cookie protocol supports the Path attribute, the
Path attribute does not provide any integrity protection because the
user agent will accept an arbitrary Path attribute in a Set-Cookie
header. For example, an HTTP response to a request for
http://example.com/foo/bar can set a cookie with a Path attribute of
"/qux". Consequently, servers SHOULD NOT both run mutually distrusting
services on different paths of the same host and use cookies store
security sensitive information.</t>
<t>An active network attacker can also inject cookies into the
Cookie header sent to https://example.com/ by impersonating a response
from http://example.com/ and injecting a Set-Cookie header. The HTTPS
server at example.com will be unable to distinguish these cookies from
cookies that it set itself in an HTTPS response. An active network
attacker might be able to leverage this ability to mount an attack
against example.com even if example.com uses HTTPS exclusively.</t>
<t>Servers can partially mitigate these attacks by encrypting and
signing the contents of their cookies. However, using cryptography
does not mitigate the issue completely because an attacker can replay
a cookie he or she received from the authentic example.com server in
the user's session, with unpredictable results.</t>
<t>Finally, an attacker might be able to force the user agent to
delete cookies by storing large number of cookies. Once the user agent
reaches its storage limit, the user agent will be forced to evict some
cookies. Servers SHOULD NOT rely upon user agents retaining
cookies.</t>
</section>
<section anchor="reliance-on-dns" title="Reliance on DNS">
<t>The cookie protocol relies upon the Domain Name System (DNS) for
security. If the DNS is partially or fully compromised, the cookie
protocol might fail to provide the security properties required by
applications.</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">
Key words for use in RFCs to Indicate Requirement Levels
</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date year="1997" month="March"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document:
<list>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.</t>
</list>
</t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" octets="4723"
target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"/>
<format type="HTML" octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
<format type="XML" octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
</reference>
<reference anchor="RFC2616">
<front>
<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding" fullname="R. Fielding">
<organization>University of California, Irvine</organization>
<address><email>fielding@ics.uci.edu</email></address>
</author>
<author initials="J." surname="Gettys" fullname="J. Gettys">
<organization>W3C</organization>
<address><email>jg@w3.org</email></address>
</author>
<author initials="J." surname="Mogul" fullname="J. Mogul">
<organization>Compaq Computer Corporation</organization>
<address><email>mogul@wrl.dec.com</email></address>
</author>
<author initials="H." surname="Frystyk" fullname="H. Frystyk">
<organization>MIT Laboratory for Computer Science</organization>
<address><email>frystyk@w3.org</email></address>
</author>
<author initials="L." surname="Masinter" fullname="L. Masinter">
<organization>Xerox Corporation</organization>
<address><email>masinter@parc.xerox.com</email></address>
</author>
<author initials="P." surname="Leach" fullname="P. Leach">
<organization>Microsoft Corporation</organization>
<address><email>paulle@microsoft.com</email></address>
</author>
<author initials="T." surname="Berners-Lee"
fullname="T. Berners-Lee">
<organization>W3C</organization>
<address><email>timbl@w3.org</email></address>
</author>
<date month="June" year="1999"/>
</front>
<seriesInfo name="RFC" value="2616"/>
</reference>
<reference anchor='RFC3492'>
<front>
<title>Punycode: A Bootstring encoding of Unicode for
Internationalized Domain Names in Applications (IDNA)</title>
<author initials='A.' surname='Costello' fullname='A. Costello'>
<organization />
</author>
<date year='2003' month='March' />
<abstract>
<t>Punycode is a simple and efficient transfer encoding syntax
designed for use with Internationalized Domain Names in Applications
(IDNA). It uniquely and reversibly transforms a Unicode string into
an ASCII string. ASCII characters in the Unicode string are
represented literally, and non-ASCII characters are represented by
ASCII characters that are allowed in host name labels (letters,
digits, and hyphens). This document defines a general algorithm
called Bootstring that allows a string of basic code points to
uniquely represent any string of code points drawn from a larger
set. Punycode is an instance of Bootstring that uses particular
parameter values specified by this document, appropriate for
IDNA.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='3492' />
<format type='TXT' octets='67439'
target='ftp://ftp.isi.edu/in-notes/rfc3492.txt' />
</reference>
<reference anchor='RFC3629'>
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials='F.' surname='Yergeau' fullname='F. Yergeau'>
<organization />
</author>
<date year='2003' month='November' />
<abstract>
<t>ISO/IEC 10646-1 defines a large character set called the
Universal Character Set (UCS) which encompasses most of the
world's writing systems. The originally proposed encodings of
the UCS, however, were not compatible with many current
applications and protocols, and this has led to the development
of UTF-8, the object of this memo. UTF-8 has the characteristic
of preserving the full US-ASCII range, providing compatibility
with file systems, parsers and other software that rely on
US-ASCII values but are transparent to other values. This memo
obsoletes and replaces RFC 2279.</t>
</abstract>
</front>
<seriesInfo name='STD' value='63' />
<seriesInfo name='RFC' value='3629' />
<format type='TXT' octets='33856'
target='ftp://ftp.rfc-editor.org/in-notes/rfc3629.txt' />
</reference>
<reference anchor="RFC5234">
<front>
<title abbrev="ABNF for Syntax Specifications">
Augmented BNF for Syntax Specifications: ABNF
</title>
<author initials="D." surname="Crocker"
fullname="Dave Crocker" role="editor">
<organization>Brandenburg InternetWorking</organization>
<address>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<author initials="P." surname="Overell" fullname="Paul Overell">
<organization>THUS plc.</organization>
<address>
<email>paul.overell@thus.net</email>
</address>
</author>
<date month="January" year="2008"/>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
</reference>
<reference anchor='RFC5246'>
<front>
<title>
The Transport Layer Security (TLS) Protocol Version 1.2
</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'>
<organization />
</author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization />
</author>
<date year='2008' month='August' />
</front>
<seriesInfo name='RFC' value='5246' />
</reference>
</references>
<references title="Informative References">
<reference anchor='RFC2109'>
<front>
<title>HTTP State Management Mechanism</title>
<author initials='D.M.' surname='Kristol' fullname='David M. Kristol'>
<organization>Bell Laboratories, Lucent Technologies</organization>
<address><email>dmk@bell-labs.com</email></address>
</author>
<author initials='L.' surname='Montulli' fullname='Lou Montulli'>
<organization>Netscape Communications Corp.</organization>
<address><email>montulli@netscape.com</email></address>
</author>
<date year='1997' month='February' />
</front>
<seriesInfo name='RFC' value='2109' />
</reference>
</references>
<section title="Acknowledgements">
<t>This document borrows heavily from RFC 2109 <xref target="RFC2109"/>.
We are indebted to David M. Kristol and Lou Montulli for their efforts to
specify the cookie protocol. David M. Kristol, in particular, provided
invaluable advice on navigating the IETF process. We would also like to
thank Thomas Broyer, Tyler Close, Bil Corry, corvid, Roy T. Fielding,
Blake Frantz, Eran Hammer-Lahav, Jeff Hodges, Achim Hoffmann, Georg
Koppen, Dean McNamee, Mark Miller, Yngve N. Pettersen, Julian Reschke,
Mark Seaborn, Maciej Stachowiak, Daniel Stenberg, David Wagner, Dan
Winship, and Dan Witte for their valuable feedback on this document.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 18:27:59 |