draft-ietf-httpstate-cookie-20.txt   draft-ietf-httpstate-cookie-21.txt 
httpstate A. Barth httpstate A. Barth
Internet-Draft U.C. Berkeley Internet-Draft U.C. Berkeley
Obsoletes: 2965 (if approved) December 19, 2010 Obsoletes: 2965 (if approved) January 20, 2011
Intended status: Standards Track Intended status: Standards Track
Expires: June 22, 2011 Expires: July 24, 2011
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpstate-cookie-20 draft-ietf-httpstate-cookie-21
Abstract Abstract
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
These header fields can be used by HTTP servers to store state These header fields can be used by HTTP servers to store state
(called cookies) at HTTP user agents, letting the servers maintain a (called cookies) at HTTP user agents, letting the servers maintain a
stateful session over the mostly stateless HTTP protocol. Although stateful session over the mostly stateless HTTP protocol. Although
cookies have many historical infelicities that degrade their security cookies have many historical infelicities that degrade their security
and privacy, the Cookie and Set-Cookie header fields are widely used and privacy, the Cookie and Set-Cookie header fields are widely used
on the Internet. on the Internet.
skipping to change at page 2, line 27 skipping to change at page 2, line 27
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 22, 2011. This Internet-Draft will expire on July 24, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 19 skipping to change at page 3, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 7 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 7
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 12 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 12
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 14 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 13
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 17 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 18 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 17
5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 18 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 17
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. Canonicalized host names . . . . . . . . . . . . . . . 20 5.1.2. Canonicalized host names . . . . . . . . . . . . . . . 19
5.1.3. Domain matching . . . . . . . . . . . . . . . . . . . 20 5.1.3. Domain matching . . . . . . . . . . . . . . . . . . . 19
5.1.4. Paths and path-match . . . . . . . . . . . . . . . . . 20 5.1.4. Paths and path-match . . . . . . . . . . . . . . . . . 19
5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 21 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 20
5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 23 5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 22
5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 24 5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 23
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 24 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 23
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 24 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 23
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 25 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 24
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 25 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 24
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 25 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 24
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 29 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 28
6. Implementation Considerations . . . . . . . . . . . . . . . . 31 6. Implementation Considerations . . . . . . . . . . . . . . . . 30
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Application Programming Interfaces . . . . . . . . . . . . 31 6.2. Application Programming Interfaces . . . . . . . . . . . . 30
6.3. IDNA dependency and migration . . . . . . . . . . . . . . 31 6.3. IDNA dependency and migration . . . . . . . . . . . . . . 30
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 33 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 32
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 33 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 32
7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 33 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . . 33
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 35 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 36 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 34
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 36 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 35
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 37 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 35
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 36
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 37 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 37
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 38 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 37
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 39 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 39 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 38
9.3. Cookie2 . . . . . . . . . . . . . . . . . . . . . . . . . 39 9.3. Cookie2 . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.4. Set-Cookie2 . . . . . . . . . . . . . . . . . . . . . . . 39 9.4. Set-Cookie2 . . . . . . . . . . . . . . . . . . . . . . . 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.1. Normative References . . . . . . . . . . . . . . . . . . . 41 10.1. Normative References . . . . . . . . . . . . . . . . . . . 40
10.2. Informative References . . . . . . . . . . . . . . . . . . 41 10.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 43 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
Using the Set-Cookie header field, an HTTP server can pass name/value Using the Set-Cookie header field, an HTTP server can pass name/value
pairs and associated metadata (called cookies) to a user agent. When pairs and associated metadata (called cookies) to a user agent. When
the user agent makes subsequent requests to the server, the user the user agent makes subsequent requests to the server, the user
agent uses the metadata and other information to determine whether to agent uses the metadata and other information to determine whether to
return the name/value pairs in the Cookie header. return the name/value pairs in the Cookie header.
skipping to change at page 5, line 30 skipping to change at page 5, line 30
For historical reasons, cookies contain a number of security and For historical reasons, cookies contain a number of security and
privacy infelicities. For example, a server can indicate that a privacy infelicities. For example, a server can indicate that a
given cookie is intended for "secure" connections, but the Secure given cookie is intended for "secure" connections, but the Secure
attribute does not provide integrity in the presence of an active attribute does not provide integrity in the presence of an active
network attacker. Similarly, cookies for a given host are shared network attacker. Similarly, cookies for a given host are shared
across all the ports on that host, even though the usual "same-origin across all the ports on that host, even though the usual "same-origin
policy" used by web browsers isolates content retrieved via different policy" used by web browsers isolates content retrieved via different
ports. ports.
There are two audiences for this specifications: developers of
cookie-generating servers and developers of cookie-consuming user
agents.
To maximize interoperability with user agents, servers SHOULD limit
themselves to the well-behaved profile defined in Section 4 when
generating cookies.
User agents MUST implement the more liberal processing rules defined
in Section 5, in order to maximize interoperability with existing
servers that do not conform to the well-behaved profile defined in
Section 4.
This document specifies the syntax and semantics of these headers as
they are actually used on the Internet. In particular, this document
does not create new syntax or semantics beyond those in use today.
The recommendations for cookie generation provided in
Section 4represent a preferred subset of current server behavior, and
even the more liberal cookie processing algorithm provided in
Section 5 does not recommend all of the syntactic and semantic
variations in use today. Where some existing software differs from
the recommended protocol in significant ways, the document contains a
note explaining the difference.
Prior to this document, there were at least three descriptions of Prior to this document, there were at least three descriptions of
cookies: the so-called "Netscape cookie specification" [Netscape], cookies: the so-called "Netscape cookie specification" [Netscape],
RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these
documents describe how the Cookie and Set-Cookie headers are actually documents describe how the Cookie and Set-Cookie headers are actually
used on the Internet (see [Kri2001] for historical context). This used on the Internet (see [Kri2001] for historical context). In
document specifies the syntax and semantics of these headers as they relation to previous IETF specifications of HTTP state management
are actually used on the Internet. mechanisms, this document requests the following actions:
In particular, this document does not create new syntax or semantics
beyond those in use today, but neither does it recommend all of the
syntactic and semantic variations in use today. The recommendations
in this document represent a preferred subset of current behaviors.
Where some existing software differs from the recommended protocol
in significant ways, the document contains a note explaining the
difference.
Therefore, in relation to previous IETF specifications of HTTP state
management mechanisms, this document requests the following actions:
1. Change the status of [RFC2109] to Historic (it has already been 1. Change the status of [RFC2109] to Historic (it has already been
obsoleted by [RFC2965]). obsoleted by [RFC2965]).
2. Change the status of [RFC2965] to Historic. 2. Change the status of [RFC2965] to Historic.
3. Indicate that [RFC2965] is obsoleted by this document. 3. Indicate that [RFC2965] is obsoleted by this document.
In particular, in moving RFC 2965 to Historic and obsoleting it, this In particular, in moving RFC 2965 to Historic and obsoleting it, this
document deprecates the use of the Cookie2 and Set-Cookie2 header document deprecates the use of the Cookie2 and Set-Cookie2 header
skipping to change at page 12, line 8 skipping to change at page 12, line 8
Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT
== User Agent -> Server == == User Agent -> Server ==
Cookie: SID=31d4d96e407aad42 Cookie: SID=31d4d96e407aad42
4. Server Requirements 4. Server Requirements
This section describes the syntax and semantics of a well-behaved This section describes the syntax and semantics of a well-behaved
profile of the Cookie and Set-Cookie headers. Servers SHOULD limit profile of the Cookie and Set-Cookie headers.
themselves to the profile described in this section, both to maximize
interoperability with existing user agents and because a future
version of the Cookie or Set-Cookie headers could remove support for
some of the esoteric semantics described in Section 5. User agents,
however, MUST implement the requirements in Section 5 to ensure
interoperability with servers making use of the full semantics.
4.1. Set-Cookie 4.1. Set-Cookie
The Set-Cookie HTTP response header is used to send cookies from the The Set-Cookie HTTP response header is used to send cookies from the
server to the user agent. server to the user agent.
4.1.1. Syntax 4.1.1. Syntax
Informally, the Set-Cookie response header contains the header name Informally, the Set-Cookie response header contains the header name
"Set-Cookie" followed by a ":" and a cookie. Each cookie begins with "Set-Cookie" followed by a ":" and a cookie. Each cookie begins with
a name-value pair, followed by zero or more attribute-value pairs. a name-value pair, followed by zero or more attribute-value pairs.
Servers SHOULD NOT send Set-Cookie headers that fail to conform to Servers SHOULD NOT send Set-Cookie headers that fail to conform to
the following grammar: the following grammar:
set-cookie-header = "Set-Cookie:" SP set-cookie-string set-cookie-header = "Set-Cookie:" SP set-cookie-string
set-cookie-string = cookie-pair *( ";" SP cookie-av ) set-cookie-string = cookie-pair *( ";" SP cookie-av )
cookie-pair = cookie-name "=" cookie-value cookie-pair = cookie-name "=" cookie-value
cookie-name = token cookie-name = token
cookie-value = token cookie-value = token / ""
token = <token, defined in [RFC2616], Section 2.2> token = <token, defined in [RFC2616], Section 2.2>
cookie-av = expires-av / max-age-av / domain-av / cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av / path-av / secure-av / httponly-av /
extension-av extension-av
expires-av = "Expires=" sane-cookie-date expires-av = "Expires=" sane-cookie-date
sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1> sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
max-age-av = "Max-Age=" non-zero-digit *DIGIT max-age-av = "Max-Age=" non-zero-digit *DIGIT
; In practice, both expires-av and max-age-av are limited ; In practice, both expires-av and max-age-av are limited
; to dates representable by the user agent. ; to dates representable by the user agent.
skipping to change at page 14, line 4 skipping to change at page 13, line 22
The portions of the set-cookie-string produced by the cookie-av term The portions of the set-cookie-string produced by the cookie-av term
are known as attributes. To maximize compatibility with user agents, are known as attributes. To maximize compatibility with user agents,
servers SHOULD NOT produce two attributes with the same name in the servers SHOULD NOT produce two attributes with the same name in the
same set-cookie-string. (See Section 5.3 for how user agents handle same set-cookie-string. (See Section 5.3 for how user agents handle
this case.) this case.)
Servers SHOULD NOT include more than one Set-Cookie header field in Servers SHOULD NOT include more than one Set-Cookie header field in
the same response with the same cookie-name. (See Section 5.2 for the same response with the same cookie-name. (See Section 5.2 for
how user agents handle this case.) how user agents handle this case.)
If a server sends multiple responses containing Set-Cookie headers If a server sends multiple responses containing Set-Cookie headers
concurrently to the user agent (e.g., when communicating with the concurrently to the user agent (e.g., when communicating with the
user agent over multiple sockets), these responses create a "race user agent over multiple sockets), these responses create a "race
condition" that can lead to unpredictable behavior. condition" that can lead to unpredictable behavior.
NOTE: Some existing user agents differ on their interpretation of NOTE: Some existing user agents differ on their interpretation of
two-digit years. To avoid compatibility issues, servers SHOULD use two-digit years. To avoid compatibility issues, servers SHOULD use
the rfc1123-date format, which requires a four-digit year. the rfc1123-date format, which requires a four-digit year.
NOTE: Some user agents represent dates using 32-bit UNIX time_t NOTE: Some user agents store and process dates in cookies as 32-bit
values. Some of these user agents might contain bugs that cause them UNIX time_t values. Implementation bugs in the libraries supporting
to process dates after the year 2038 incorrectly. time_t processing on some systems might cause such user agents to
process dates after the year 2038 incorrectly.
4.1.2. Semantics (Non-Normative) 4.1.2. Semantics (Non-Normative)
This section describes a simplified semantics of the Set-Cookie This section describes a simplified semantics of the Set-Cookie
header. These semantics are detailed enough to be useful for header. These semantics are detailed enough to be useful for
understanding the most common uses of cookies by servers. The full understanding the most common uses of cookies by servers. The full
semantics are described in Section 5. semantics are described in Section 5.
When the user agent receives a Set-Cookie header, the user agent When the user agent receives a Set-Cookie header, the user agent
stores the cookie together with its attributes. Subsequently, when stores the cookie together with its attributes. Subsequently, when
skipping to change at page 18, line 7 skipping to change at page 17, line 7
Although cookies are serialized linearly in the Cookie header, Although cookies are serialized linearly in the Cookie header,
servers SHOULD NOT rely upon the serialization order. In particular, servers SHOULD NOT rely upon the serialization order. In particular,
if the Cookie header contains two cookies with the same name (e.g., if the Cookie header contains two cookies with the same name (e.g.,
that were set with different Path or Domain attributes), servers that were set with different Path or Domain attributes), servers
SHOULD NOT rely upon the order in which these cookies appear in the SHOULD NOT rely upon the order in which these cookies appear in the
header. header.
5. User Agent Requirements 5. User Agent Requirements
For historical reasons, the full semantics of cookies (as presently This section specifies the Cookie and Set-Cookie headers in
deployed on the Internet) contain a number of exotic quirks. This sufficient detail that a user agent implementing these requirements
section is intended to specify the Cookie and Set-Cookie headers in precisely can interoperate with existing servers (even those that do
sufficient detail to allow a user agent implementing these not conform to the well-behaved profile described in Section 4.
requirements precisely to interoperate with existing servers.
5.1. Subcomponent Algorithms 5.1. Subcomponent Algorithms
This section defines some algorithms used by user agents to process This section defines some algorithms used by user agents to process
specific subcomponents of the Cookie and Set-Cookie headers. specific subcomponents of the Cookie and Set-Cookie headers.
5.1.1. Dates 5.1.1. Dates
The user agent MUST use an algorithm equivalent to the following The user agent MUST use an algorithm equivalent to the following
algorithm to parse a cookie-date. Note that the various boolean algorithm to parse a cookie-date. Note that the various boolean
skipping to change at page 18, line 39 skipping to change at page 17, line 38
date-token = 1*non-delimiter date-token = 1*non-delimiter
delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
non-digit = %x00-2F / %x3A-FF non-digit = %x00-2F / %x3A-FF
day-of-month = 1*2DIGIT ( non-digit *OCTET ) day-of-month = 1*2DIGIT ( non-digit *OCTET )
month = ( "jan" / "feb" / "mar" / "apr" / month = ( "jan" / "feb" / "mar" / "apr" /
"may" / "jun" / "jul" / "aug" / "may" / "jun" / "jul" / "aug" /
"sep" / "oct" / "nov" / "dec" ) *OCTET "sep" / "oct" / "nov" / "dec" ) *OCTET
year = 1*4DIGIT ( non-digit *OCTET ) year = 2*4DIGIT ( non-digit *OCTET )
time = hms-time ( non-digit *OCTET ) time = hms-time ( non-digit *OCTET )
hms-time = time-field ":" time-field ":" time-field hms-time = time-field ":" time-field ":" time-field
time-field = 1*2DIGIT time-field = 1*2DIGIT
2. Process each date-token sequentially in the order the date-tokens 2. Process each date-token sequentially in the order the date-tokens
appear in the cookie-date: appear in the cookie-date:
1. If the found-time flag is not set and the token matches the 1. If the found-time flag is not set and the token matches the
time production, set the found-time flag and set the hour- time production, set the found-time flag and set the hour-
value, minute-value, and second-value to the numbers denoted value, minute-value, and second-value to the numbers denoted
skipping to change at page 21, line 32 skipping to change at page 20, line 32
o The cookie-path is a prefix of the request-path and the first o 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- character of the request-path that is not included in the cookie-
path is a %x2F ("/") character. path is a %x2F ("/") character.
5.2. The Set-Cookie Header 5.2. The Set-Cookie Header
When a user agent receives a Set-Cookie header field in an HTTP When a user agent receives a Set-Cookie header field in an HTTP
response, the user agent MAY ignore the Set-Cookie header field in response, the user agent MAY ignore the Set-Cookie header field in
its entirety. For example, the user agent might wish to block its entirety. For example, the user agent might wish to block
responses to "third-party" requests from setting cookies. responses to "third-party" requests from setting cookies (See
Section 7.1).
If the user agent does not ignore the Set-Cookie header field in its If the user agent does not ignore the Set-Cookie header field in its
entirety, the user agent MUST parse the field-value of the Set-Cookie entirety, the user agent MUST parse the field-value of the Set-Cookie
header field as a set-cookie-string (defined below). header field as a set-cookie-string (defined below).
NOTE: The algorithm below is more permissive than the grammar in NOTE: The algorithm below is more permissive than the grammar in
Section 4.1. For example, the algorithm strips leading and trailing Section 4.1. For example, the algorithm strips leading and trailing
whitespace from the cookie name and value (but maintains internal whitespace from the cookie name and value (but maintains internal
whitespace), whereas the grammar in Section 4.1 forbids whitespace in whitespace), whereas the grammar in Section 4.1 forbids whitespace in
these positions. User agents use this algorithm so as to these positions. User agents use this algorithm so as to
skipping to change at page 29, line 15 skipping to change at page 28, line 15
5.4. The Cookie Header 5.4. The Cookie Header
The user agent includes stored cookies in the Cookie HTTP request The user agent includes stored cookies in the Cookie HTTP request
header. header.
When the user agent generates an HTTP request, the user agent MUST When the user agent generates an HTTP request, the user agent MUST
NOT attach more than one Cookie header field. NOT attach more than one Cookie header field.
A user agent MAY omit the Cookie header in its entirety. For A user agent MAY omit the Cookie header in its entirety. For
example, the user agent might wish to block sending cookies during example, the user agent might wish to block sending cookies during
"third-party" requests. "third-party" requests from setting cookies (See Section 7.1).
If the user agent does attach a Cookie header field to an HTTP If the user agent does attach a Cookie header field to an HTTP
request, the user agent MUST send the cookie-string (defined below) request, the user agent MUST send the cookie-string (defined below)
as the value of the header field. as the value of the header field.
The user agent MUST use an algorithm equivalent to the following The user agent MUST use an algorithm equivalent to the following
algorithm to compute the "cookie-string" from a cookie store and a algorithm to compute the "cookie-string" from a cookie store and a
request-uri: request-uri:
1. Let cookie-list be the set of cookies from the cookie store that 1. Let cookie-list be the set of cookies from the cookie store that
skipping to change at page 30, line 39 skipping to change at page 29, line 39
1. Output the cookie's name, the %x3D ("=") character, and the 1. Output the cookie's name, the %x3D ("=") character, and the
cookie's value. cookie's value.
2. If there is an unprocessed cookie in the cookie-list, output 2. If there is an unprocessed cookie in the cookie-list, output
the characters %x3B and %x20 ("; "). the characters %x3B and %x20 ("; ").
NOTE: Despite its name, the cookie-string is actually a sequence of NOTE: Despite its name, the cookie-string is actually a sequence of
octets, not a sequence of characters. To convert the cookie-string octets, not a sequence of characters. To convert the cookie-string
(or components thereof) into a sequence of characters (e.g., for (or components thereof) into a sequence of characters (e.g., for
presentation to the user), the user agent might wish use the UTF-8 presentation to the user), the user agent might wish to try using the
character encoding [RFC3629] to decode the octet sequence. UTF-8 character encoding [RFC3629] to decode the octet sequence.
This decoding might fail, however, because not every sequence of
octets is valid UTF-8.
6. Implementation Considerations 6. Implementation Considerations
6.1. Limits 6.1. Limits
Practical user agent implementations have limits on the number and Practical user agent implementations have limits on the number and
size of cookies that they can store. General-use user agents SHOULD size of cookies that they can store. General-use user agents SHOULD
provide each of the following minimum capabilities: provide each of the following minimum capabilities:
o At least 4096 bytes per cookie (as measured by the sum of the o At least 4096 bytes per cookie (as measured by the sum of the
skipping to change at page 33, line 21 skipping to change at page 32, line 21
track users across HTTP requests, cookies facilitate tracking because track users across HTTP requests, cookies facilitate tracking because
they are persistent across user agent sessions and can be shared they are persistent across user agent sessions and can be shared
between hosts. between hosts.
7.1. Third-Party Cookies 7.1. Third-Party Cookies
Particularly worrisome are so-called "third-party" cookies. In Particularly worrisome are so-called "third-party" cookies. In
rendering an HTML document, a user agent often requests resources rendering an HTML document, a user agent often requests resources
from other servers (such as advertising networks). These third-party from other servers (such as advertising networks). These third-party
servers can use cookies to track the user even if the user never servers can use cookies to track the user even if the user never
visits the server directly. visits the server directly. For example, if a user visits a site
that contains content from a third party and then later visits
another site that contains content from the same third party, the
third party can track the user between the two sites.
Some user agents restrict how third-party cookies behave. For Some user agents restrict how third-party cookies behave. For
example, some of these user agents refuse to send the Cookie header example, some of these user agents refuse to send the Cookie header
in third-party requests. Others refuse to process the Set-Cookie in third-party requests. Others refuse to process the Set-Cookie
header in responses to third-party requests. User agents vary widely header in responses to third-party requests. User agents vary widely
in their third-party cookie policies. This document grants user in their third-party cookie policies. This document grants user
agents wide latitude to experiment with third-party cookie policies agents wide latitude to experiment with third-party cookie policies
that balance the privacy and compatibility needs of their users. that balance the privacy and compatibility needs of their users.
However, this document does not endorse any particular third-party However, this document does not endorse any particular third-party
cookie policy. cookie policy.
Third-party cookie blocking policies are often ineffective at Third-party cookie blocking policies are often ineffective at
achieving their privacy goals if servers attempt to work around their achieving their privacy goals if servers attempt to work around their
restrictions to track users. In particular, two collaborating restrictions to track users. In particular, two collaborating
servers can often track users without using cookies at all by servers can often track users without using cookies at all by
injecting identifying information into dynamic URLs. injecting identifying information into dynamic URLs.
7.2. User Controls 7.2. User Controls
User agents should provide users with a mechanism for managing the User agents SHOULD provide users with a mechanism for managing the
cookies stored in the cookie store. For example, a user agent might cookies stored in the cookie store. For example, a user agent might
let users delete all cookies received during a specified time period let users delete all cookies received during a specified time period
or all the cookies related to a particular domain. In addition, many or all the cookies related to a particular domain. In addition, many
user agents include a user interface element that lets users examine user agents include a user interface element that lets users examine
the cookies stored in their cookie store. the cookies stored in their cookie store.
User agents should provide users with a mechanism for disabling User agents SHOULD provide users with a mechanism for disabling
cookies. When cookies are disabled, the user agent MUST NOT include cookies. When cookies are disabled, the user agent MUST NOT include
a Cookie header in outbound HTTP requests and the user agent MUST NOT a Cookie header in outbound HTTP requests and the user agent MUST NOT
process Set-Cookie headers in inbound HTTP responses. process Set-Cookie headers in inbound HTTP responses.
Some user agents provide users the option of preventing persistent Some user agents provide users the option of preventing persistent
storage of cookies across sessions. When configured thusly, user storage of cookies across sessions. When configured thusly, user
agents MUST treat all received cookies as if the persistent-flag were agents MUST treat all received cookies as if the persistent-flag were
set to false. set to false. Some popular user agents expose this functionality via
"private browsing" mode [Aggarwal2010]
Some user agents provide users with the ability to approve individual Some user agents provide users with the ability to approve individual
writes to the cookie store. In many common usage scenarios, these writes to the cookie store. In many common usage scenarios, these
controls generate a large number of prompts. However, some privacy- controls generate a large number of prompts. However, some privacy-
conscious users find these controls useful nonetheless. conscious users find these controls useful nonetheless.
7.3. Expiration Dates
Although servers can set the expiration date for cookies to the
distant future, most user agents do not actually retain cookies for
multiple decades. Rather than chosing gratiously long expiration
periods, servers SHOULD promote user privacy by selecting reasonable
cookie expiration periods based on the purpose of the cookie. For
example, a typical session identifier might reasonably be set to
expire in two weeks.
8. Security Considerations 8. Security Considerations
8.1. Overview 8.1. Overview
Cookies have a number of security pitfalls. This section overviews a Cookies have a number of security pitfalls. This section overviews a
few of the more salient issues. few of the more salient issues.
In particular, cookies encourage developers to rely on ambient In particular, cookies encourage developers to rely on ambient
authority for authentication, often becoming vulnerable to attacks authority for authentication, often becoming vulnerable to attacks
such as cross-site request forgery [CSRF]. Also, when storing such as cross-site request forgery [CSRF]. Also, when storing
skipping to change at page 36, line 19 skipping to change at page 35, line 19
1. All sensitive information conveyed in these headers is exposed to 1. All sensitive information conveyed in these headers is exposed to
an eavesdropper. an eavesdropper.
2. A malicious intermediary could alter the headers as they travel 2. A malicious intermediary could alter the headers as they travel
in either direction, with unpredictable results. in either direction, with unpredictable results.
3. A malicious client could alter the Cookie header before 3. A malicious client could alter the Cookie header before
transmission, with unpredictable results. transmission, with unpredictable results.
Servers SHOULD encrypt and sign the contents of cookies when Servers SHOULD encrypt and sign the contents of cookies (using
transmitting them to the user agent (even when sending the cookies whatever format the server desires) when transmitting them to the
over a secure channel). However, encrypting and signing cookie user agent (even when sending the cookies over a secure channel).
contents does not prevent an attacker from transplanting a cookie However, encrypting and signing cookie contents does not prevent an
from one user agent to another or from replaying the cookie at a attacker from transplanting a cookie from one user agent to another
later time. or from replaying the cookie at a later time.
In addition to encrypting and signing the contents of every cookie, In addition to encrypting and signing the contents of every cookie,
servers that require a higher level of security SHOULD use the Cookie servers that require a higher level of security SHOULD use the Cookie
and Set-Cookie headers only over a secure channel. When using and Set-Cookie headers only over a secure channel. When using
cookies over a secure channel, servers SHOULD set the Secure cookies over a secure channel, servers SHOULD set the Secure
attribute (see Section 4.1.2.5) for every cookie. If a server does attribute (see Section 4.1.2.5) for every cookie. If a server does
not set the Secure attribute, the protection provided by the secure not set the Secure attribute, the protection provided by the secure
channel will be largely moot. channel will be largely moot.
For example, consider a webmail server that stores a session
identifier in a cookie and is typically accessed over HTTPS. If the
server does not set the Secure attribute on its cookies, an active
network attacker can intercept any outbound HTTP request from the
user agent and redirect that request to the webmail server over HTTP.
Even if the webmail server is not listening for HTTP connections, the
user agent will still include cookies in the request. The active
network attacker can intercept these cookies, reply them against the
server, and learn the contents of the user's email. If, instead, the
server had set the Secure attribute on its cookies, the user agent
would not have included the cookies in the clear-text request.
8.4. Session Identifiers 8.4. Session Identifiers
Instead of storing session information directly in a cookie (where it Instead of storing session information directly in a cookie (where it
might be exposed to or replayed by an attacker), servers commonly might be exposed to or replayed by an attacker), servers commonly
store a nonce (or "session identifier") in a cookie. When the server 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 receives an HTTP request with a nonce, the server can look up state
information associated with the cookie using the nonce as a key. information associated with the cookie using the nonce as a key.
Using session identifier cookies limits the damage an attacker can Using session identifier cookies limits the damage an attacker can
cause if the attacker learns the contents of a cookie because the cause if the attacker learns the contents of a cookie because the
skipping to change at page 43, line 5 skipping to change at page 41, line 38
[UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility
Processing", Unicode Technical Standards # 46, 2010, Processing", Unicode Technical Standards # 46, 2010,
<http://unicode.org/reports/tr46/>. <http://unicode.org/reports/tr46/>.
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses [CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses
for Cross-Site Request Forgery", 2008, <http:// for Cross-Site Request Forgery", 2008, <http://
www.adambarth.com/papers/2008/ www.adambarth.com/papers/2008/
barth-jackson-mitchell-b.pdf>. barth-jackson-mitchell-b.pdf>.
[Aggarwal2010]
Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh,
"An Analysis of Private Browsing Modes in Modern
Browsers", 2010, <http://www.collinjackson.com/research/
private-browsing.pdf>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
This document borrows heavily from RFC 2109 [RFC2109]. We are This document borrows heavily from RFC 2109 [RFC2109]. We are
indebted to David M. Kristol and Lou Montulli for their efforts to indebted to David M. Kristol and Lou Montulli for their efforts to
specify cookies. David M. Kristol, in particular, provided specify cookies. David M. Kristol, in particular, provided
invaluable advice on navigating the IETF process. We would also like invaluable advice on navigating the IETF process. We would also like
to thank Thomas Broyer, Tyler Close, Bil Corry, corvid, Lisa to thank Thomas Broyer, Tyler Close, Alissa Cooper, Bil Corry,
Dusseault, Roy T. Fielding, Blake Frantz, Anne van Kesteren, Eran corvid, Lisa Dusseault, Roy T. Fielding, Blake Frantz, Anne van
Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim Hoffmann, Georg Kesteren, Eran Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim
Koppen, Dean McNamee, Alexey Melnikov, Mark Miller, Mark Pauley, Hoffmann, Georg Koppen, Dean McNamee, Alexey Melnikov, Mark Miller,
Yngve N. Pettersen, Julian Reschke, Peter Saint-Andre, Mark Seaborn, Mark Pauley, Yngve N. Pettersen, Julian Reschke, Peter Saint-Andre,
Maciej Stachowiak, Daniel Stenberg, Tatsuhiro Tsujikawa, David Mark Seaborn, Maciej Stachowiak, Daniel Stenberg, Tatsuhiro
Wagner, Dan Winship, and Dan Witte for their valuable feedback on Tsujikawa, David Wagner, Dan Winship, and Dan Witte for their
this document. valuable feedback on this document.
Author's Address Author's Address
Adam Barth Adam Barth
University of California, Berkeley University of California, Berkeley
Email: abarth@eecs.berkeley.edu Email: abarth@eecs.berkeley.edu
URI: http://www.adambarth.com/ URI: http://www.adambarth.com/
 End of changes. 28 change blocks. 
99 lines changed or deleted 143 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/