draft-ietf-httpstate-cookie-23.txt   rfc6265.txt 
httpstate A. Barth Internet Engineering Task Force (IETF) A. Barth
Internet-Draft U.C. Berkeley Request for Comments: 6265 U.C. Berkeley
Obsoletes: 2965 (if approved) March 1, 2011 Obsoletes: 2965 April 2011
Intended status: Standards Track Category: Standards Track
Expires: September 2, 2011 ISSN: 2070-1721
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpstate-cookie-23
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. This document obsoletes [RFC2965]. on the Internet. This document obsoletes RFC 2965.
Editorial Note (To be removed by RFC Editor)
If you have suggestions for improving this document, please send
email to <mailto:http-state@ietf.org>. Suggestions with test cases
are especially appreciated. Further Working Group information is
available from <https://tools.ietf.org/wg/httpstate/>.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 2, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6265.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 3, line 9 skipping to change at page 2, line 19
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Conventions .....................................................4
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 7 2.1. Conformance Criteria .......................................4
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 2.2. Syntax Notation ............................................5
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Terminology ................................................5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Overview ........................................................6
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Examples ...................................................6
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 12 4. Server Requirements .............................................8
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Set-Cookie .................................................8
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Syntax ..............................................8
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 13 4.1.2. Semantics (Non-Normative) ..........................10
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Cookie ....................................................13
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Syntax .............................................13
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16 4.2.2. Semantics ..........................................13
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 18 5. User Agent Requirements ........................................14
5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 18 5.1. Subcomponent Algorithms ...................................14
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1.1. Dates ..............................................14
5.1.2. Canonicalized host names . . . . . . . . . . . . . . . 20 5.1.2. Canonicalized Host Names ...........................16
5.1.3. Domain matching . . . . . . . . . . . . . . . . . . . 20 5.1.3. Domain Matching ....................................16
5.1.4. Paths and path-match . . . . . . . . . . . . . . . . . 20 5.1.4. Paths and Path-Match ...............................16
5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 21 5.2. The Set-Cookie Header .....................................17
5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 23 5.2.1. The Expires Attribute ..............................19
5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 24 5.2.2. The Max-Age Attribute ..............................20
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 24 5.2.3. The Domain Attribute ...............................20
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 25 5.2.4. The Path Attribute .................................21
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 25 5.2.5. The Secure Attribute ...............................21
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 25 5.2.6. The HttpOnly Attribute .............................21
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 25 5.3. Storage Model .............................................21
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 29 5.4. The Cookie Header .........................................25
6. Implementation Considerations . . . . . . . . . . . . . . . . 31 6. Implementation Considerations ..................................27
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1. Limits ....................................................27
6.2. Application Programming Interfaces . . . . . . . . . . . . 31 6.2. Application Programming Interfaces ........................27
6.3. IDNA dependency and migration . . . . . . . . . . . . . . 31 6.3. IDNA Dependency and Migration .............................27
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 33 7. Privacy Considerations .........................................28
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 33 7.1. Third-Party Cookies .......................................28
7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 33 7.2. User Controls .............................................28
7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . . 34 7.3. Expiration Dates ..........................................29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations ........................................29
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.1. Overview ..................................................29
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 35 8.2. Ambient Authority .........................................30
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 36 8.3. Clear Text ................................................30
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 36 8.4. Session Identifiers .......................................31
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 37 8.5. Weak Confidentiality ......................................32
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 38 8.6. Weak Integrity ............................................32
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 38 8.7. Reliance on DNS ...........................................33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 9. IANA Considerations ............................................33
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 39 9.1. Cookie ....................................................34
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 39 9.2. Set-Cookie ................................................34
9.3. Cookie2 . . . . . . . . . . . . . . . . . . . . . . . . . 39 9.3. Cookie2 ...................................................34
9.4. Set-Cookie2 . . . . . . . . . . . . . . . . . . . . . . . 39 9.4. Set-Cookie2 ...............................................34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 10. References ....................................................35
10.1. Normative References . . . . . . . . . . . . . . . . . . . 41 10.1. Normative References .....................................35
10.2. Informative References . . . . . . . . . . . . . . . . . . 41 10.2. Informative References ...................................35
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 43 Appendix A. Acknowledgements ......................................37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44
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.
Although simple on their surface, cookies have a number of Although simple on their surface, cookies have a number of
complexities. For example, the server indicates a scope for each complexities. For example, the server indicates a scope for each
cookie when sending it to the user agent. The scope indicates the cookie when sending it to the user agent. The scope indicates the
maximum amount of time the user agent should return the cookie, the maximum amount of time in which the user agent should return the
servers to which the user agent should return the cookie, and the URI cookie, the servers to which the user agent should return the cookie,
schemes for which the cookie is applicable. and the URI schemes for which the cookie is applicable.
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 There are two audiences for this specification: developers of cookie-
cookie-generating servers and developers of cookie-consuming user generating servers and developers of cookie-consuming user agents.
agents.
To maximize interoperability with user agents, servers SHOULD limit To maximize interoperability with user agents, servers SHOULD limit
themselves to the well-behaved profile defined in Section 4 when themselves to the well-behaved profile defined in Section 4 when
generating cookies. generating cookies.
User agents MUST implement the more liberal processing rules defined User agents MUST implement the more liberal processing rules defined
in Section 5, in order to maximize interoperability with existing in Section 5, in order to maximize interoperability with existing
servers that do not conform to the well-behaved profile defined in servers that do not conform to the well-behaved profile defined in
Section 4. Section 4.
skipping to change at page 6, line 18 skipping to change at page 4, line 38
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). In used on the Internet (see [Kri2001] for historical context). In
relation to previous IETF specifications of HTTP state management relation to previous IETF specifications of HTTP state management
mechanisms, this document requests the following actions: 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] has been 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
fields. fields.
2. Conventions 2. Conventions
2.1. Conformance Criteria 2.1. Conformance Criteria
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Requirements phrased in the imperative as part of algorithms (such as Requirements phrased in the imperative as part of algorithms (such as
"strip any leading space characters" or "return false and abort these "strip any leading space characters" or "return false and abort these
steps") are to be interpreted with the meaning of the key word steps") are to be interpreted with the meaning of the key word
("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm. ("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm.
Conformance requirements phrased as algorithms or specific steps can Conformance requirements phrased as algorithms or specific steps can
be implemented in any manner, so long as the end result is be implemented in any manner, so long as the end result is
equivalent. In particular, the algorithms defined in this equivalent. In particular, the algorithms defined in this
specification are intended to be easy to understand and are not specification are intended to be easy to understand and are not
intended to be performant. intended to be performant.
2.2. Syntax Notation 2.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234]. notation of [RFC5234].
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet),
OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB
(horizontal tab), CHAR (any [USASCII] character), VCHAR (any visible (horizontal tab), CHAR (any [USASCII] character), VCHAR (any visible
[USASCII] character), and WSP (whitespace). [USASCII] character), and WSP (whitespace).
The OWS (optional whitespace) rule is used where zero or more linear The OWS (optional whitespace) rule is used where zero or more linear
whitespace characters MAY appear: whitespace characters MAY appear:
OWS = *( [ obs-fold ] WSP ) OWS = *( [ obs-fold ] WSP )
; "optional" whitespace ; "optional" whitespace
skipping to change at page 8, line 6 skipping to change at page 5, line 46
OWS SHOULD either not be produced or be produced as a single SP OWS SHOULD either not be produced or be produced as a single SP
character. character.
2.3. Terminology 2.3. Terminology
The terms user agent, client, server, proxy, and origin server have The terms user agent, client, server, proxy, and origin server have
the same meaning as in the HTTP/1.1 specification ([RFC2616], Section the same meaning as in the HTTP/1.1 specification ([RFC2616], Section
1.3). 1.3).
The request-host is the name of the host, as known by the user agent, The request-host is the name of the host, as known by the user agent,
to which the user agent is sending an HTTP request or is receiving an to which the user agent is sending an HTTP request or from which it
HTTP response from (i.e., the name of the host to which it sent the is receiving an HTTP response (i.e., the name of the host to which it
corresponding HTTP request). sent the corresponding HTTP request).
The term request-uri is defined in Section 5.1.2 of [RFC2616]. The term request-uri is defined in Section 5.1.2 of [RFC2616].
Two sequences of octets are said to case-insensitively match each Two sequences of octets are said to case-insensitively match each
other if and only if they are equivalent under the i;ascii-casemap other if and only if they are equivalent under the i;ascii-casemap
collation defined in [RFC4790]. collation defined in [RFC4790].
The term string means a sequence of non-NUL octets. The term string means a sequence of non-NUL octets.
3. Overview 3. Overview
skipping to change at page 10, line 19 skipping to change at page 7, line 31
== User Agent -> Server == == User Agent -> Server ==
Cookie: SID=31d4d96e407aad42 Cookie: SID=31d4d96e407aad42
As shown in the next example, the server can store multiple cookies As shown in the next example, the server can store multiple cookies
at the user agent. For example, the server can store a session at the user agent. For example, the server can store a session
identifier as well as the user's preferred language by returning two identifier as well as the user's preferred language by returning two
Set-Cookie header fields. Notice that the server uses the Secure and Set-Cookie header fields. Notice that the server uses the Secure and
HttpOnly attributes to provide additional security protections for HttpOnly attributes to provide additional security protections for
the more-sensitive session identifier (see Section 4.1.2.) the more sensitive session identifier (see Section 4.1.2.)
== Server -> User Agent == == Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
Set-Cookie: lang=en-US; Path=/; Domain=example.com Set-Cookie: lang=en-US; Path=/; Domain=example.com
== User Agent -> Server == == User Agent -> Server ==
Cookie: SID=31d4d96e407aad42; lang=en-US Cookie: SID=31d4d96e407aad42; lang=en-US
skipping to change at page 12, line 19 skipping to change at page 8, line 41
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 = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE ) cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
; US-ASCII characters excluding CTLs, ; US-ASCII characters excluding CTLs,
skipping to change at page 13, line 22 skipping to change at page 10, line 4
To maximize compatibility with user agents, servers that wish to To maximize compatibility with user agents, servers that wish to
store arbitrary data in a cookie-value SHOULD encode that data, for store arbitrary data in a cookie-value SHOULD encode that data, for
example, using Base64 [RFC4648]. example, using Base64 [RFC4648].
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 in 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 store and process dates in cookies as 32-bit NOTE: Some user agents store and process dates in cookies as 32-bit
UNIX time_t values. Implementation bugs in the libraries supporting UNIX time_t values. Implementation bugs in the libraries supporting
time_t processing on some systems might cause such user agents to time_t processing on some systems might cause such user agents to
process dates after the year 2038 incorrectly. 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 simplified semantics of the Set-Cookie header.
header. These semantics are detailed enough to be useful for These semantics are detailed enough to be useful for understanding
understanding the most common uses of cookies by servers. The full the most common uses of cookies by servers. The full semantics are
semantics are described in Section 5. 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
the user agent makes an HTTP request, the user agent includes the the user agent makes an HTTP request, the user agent includes the
applicable, non-expired cookies in the Cookie header. applicable, non-expired cookies in the Cookie header.
If the user agent receives a new cookie with the same cookie-name, If the user agent receives a new cookie with the same cookie-name,
domain-value, and path-value as a cookie that it has already stored, domain-value, and path-value as a cookie that it has already stored,
the existing cookie is evicted and replaced with the new cookie. the existing cookie is evicted and replaced with the new cookie.
Notice that servers can delete cookies by sending the user agent a Notice that servers can delete cookies by sending the user agent a
new cookie with an Expires attribute with a value in the past. new cookie with an Expires attribute with a value in the past.
Unless the cookie's attributes indicate otherwise, the cookie is Unless the cookie's attributes indicate otherwise, the cookie is
returned only to the origin server (and not, e.g., to any returned only to the origin server (and not, for example, to any
subdomains), and it expires at the end of the current session (as subdomains), and it expires at the end of the current session (as
defined by the user agent). User agents ignore unrecognized cookie defined by the user agent). User agents ignore unrecognized cookie
attributes (but not the entire cookie). attributes (but not the entire cookie).
4.1.2.1. The Expires Attribute 4.1.2.1. The Expires Attribute
The Expires attribute indicates the maximum lifetime of the cookie, The Expires attribute indicates the maximum lifetime of the cookie,
represented as the date and time at which the cookie expires. The represented as the date and time at which the cookie expires. The
user agent is not required to retain the cookie until the specified user agent is not required to retain the cookie until the specified
date has passed. In fact, user agents often evict cookies due to date has passed. In fact, user agents often evict cookies due to
memory pressure or privacy concerns. memory pressure or privacy concerns.
4.1.2.2. The Max-Age Attribute 4.1.2.2. The Max-Age Attribute
The Max-Age attribute indicates the maximum lifetime of the cookie, The Max-Age attribute indicates the maximum lifetime of the cookie,
represented as the number of seconds until the cookie expires. The represented as the number of seconds until the cookie expires. The
user agent is not required to retain the cookie for the specified user agent is not required to retain the cookie for the specified
duration. In fact, user agents often evict cookies from due to duration. In fact, user agents often evict cookies due to memory
memory pressure or privacy concerns. pressure or privacy concerns.
NOTE: Some existing user agents do not support the Max-Age NOTE: Some existing user agents do not support the Max-Age
attribute. User agents that do not support the Max-Age attribute attribute. User agents that do not support the Max-Age attribute
ignore the attribute. ignore the attribute.
If a cookie has both the Max-Age and the Expires attribute, the Max- 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 Age attribute has precedence and controls the expiration date of the
cookie. If a cookie has neither the Max-Age nor the Expires cookie. If a cookie has neither the Max-Age nor the Expires
attribute, the user agent will retain the cookie until "the current attribute, the user agent will retain the cookie until "the current
session is over" (as defined by the user agent). session is over" (as defined by the user agent).
skipping to change at page 19, line 33 skipping to change at page 15, line 36
3. If the year-value is greater than or equal to 70 and less than or 3. If the year-value is greater than or equal to 70 and less than or
equal to 99, increment the year-value by 1900. equal to 99, increment the year-value by 1900.
4. If the year-value is greater than or equal to 0 and less than or 4. If the year-value is greater than or equal to 0 and less than or
equal to 69, increment the year-value by 2000. equal to 69, increment the year-value by 2000.
1. NOTE: Some existing user agents interpret two-digit years 1. NOTE: Some existing user agents interpret two-digit years
differently. differently.
5. Abort these steps and fail to parse the cookie-date if 5. Abort these steps and fail to parse the cookie-date if:
* at least one of the found-day-of-month, found-month, found- * at least one of the found-day-of-month, found-month, found-
year, or found-time flags is not set, year, or found-time flags is not set,
* the day-of-month-value is less than 1 or greater than 31, * the day-of-month-value is less than 1 or greater than 31,
* the year-value is less than 1601, * the year-value is less than 1601,
* the hour-value is greater than 23, * the hour-value is greater than 23,
skipping to change at page 20, line 10 skipping to change at page 16, line 13
(Note that leap seconds cannot be represented in this syntax.) (Note that leap seconds cannot be represented in this syntax.)
6. Let the parsed-cookie-date be the date whose day-of-month, month, 6. Let the parsed-cookie-date be the date whose day-of-month, month,
year, hour, minute, and second (in UTC) are the day-of-month- year, hour, minute, and second (in UTC) are the day-of-month-
value, the month-value, the year-value, the hour-value, the value, the month-value, the year-value, the hour-value, the
minute-value, and the second-value, respectively. If no such minute-value, and the second-value, respectively. If no such
date exists, abort these steps and fail to parse the cookie-date. date exists, abort these steps and fail to parse the cookie-date.
7. Return the parsed-cookie-date as the result of this algorithm. 7. Return the parsed-cookie-date as the result of this algorithm.
5.1.2. Canonicalized host names 5.1.2. Canonicalized Host Names
A canonicalized host name is the string generated by the following A canonicalized host name is the string generated by the following
algorithm: algorithm:
1. Convert the host name to a sequence of individual domain name 1. Convert the host name to a sequence of individual domain name
labels. labels.
2. Convert each label that is not a NR-LDH label, to a A-label (see 2. Convert each label that is not a Non-Reserved LDH (NR-LDH) label,
Section 2.3.2.1 of [RFC5890] for the fomer and latter), or to a to an A-label (see Section 2.3.2.1 of [RFC5890] for the former
"punycode label" (a label resulting from the "ToASCII" conversion and latter), or to a "punycode label" (a label resulting from the
in Section 4 of [RFC3490]), as appropriate (see Section 6.3 of "ToASCII" conversion in Section 4 of [RFC3490]), as appropriate
this specification). (see Section 6.3 of this specification).
3. Concatentate the resulting labels, separated by a %x2E (".") 3. Concatenate the resulting labels, separated by a %x2E (".")
character. character.
5.1.3. Domain matching 5.1.3. Domain Matching
A string domain-matches a given domain string if at least one of the A string domain-matches a given domain string if at least one of the
following conditions hold: following conditions hold:
o The domain string and the string are identical. (Note that both o The domain string and the string are identical. (Note that both
the domain string and the string will have been canonicalized to the domain string and the string will have been canonicalized to
lower case at this point.) lower case at this point.)
o All of the following conditions hold: o All of the following conditions hold:
* The domain string is a suffix of the string. * The domain string is a suffix of the string.
* The last character of the string that is not included in the * The last character of the string that is not included in the
domain string is a %x2E (".") character. domain string is a %x2E (".") character.
* The string is a host name (i.e., not an IP address). * The string is a host name (i.e., not an IP address).
5.1.4. Paths and path-match 5.1.4. Paths and Path-Match
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 default-path of a cookie: algorithm to compute the default-path of a cookie:
1. Let uri-path be the path portion of the request-uri if such a 1. Let uri-path be the path portion of the request-uri if such a
portion exists (and empty otherwise). For example, if the portion exists (and empty otherwise). For example, if the
request-uri contains just a path (and optional query string), request-uri contains just a path (and optional query string),
then the uri-path is that path (without the %x3F ("?") character then the uri-path is that path (without the %x3F ("?") character
or query string), and if the request-uri contains a full or query string), and if the request-uri contains a full
absoluteURI, the uri-path is the path component of that URI. absoluteURI, the uri-path is the path component of that URI.
2. If the uri-path is empty or if the first character of the uri- 2. If the uri-path is empty or if the first character of the uri-
path is not a %x2F ("/") character, output %x2F ("/") and skip path is not a %x2F ("/") character, output %x2F ("/") and skip
the remaining steps. the remaining steps.
3. If the uri-path contains only a single %x2F ("/") character, 3. If the uri-path contains no more than one %x2F ("/") character,
output %x2F ("/") and skip the remaining steps. output %x2F ("/") and skip the remaining step.
4. Output the characters of the uri-path from the first character up 4. Output the characters of the uri-path from the first character up
to, but not including, the right-most %x2F ("/"). to, but not including, the right-most %x2F ("/").
A request-path path-matches a given cookie-path if at least one of A request-path path-matches a given cookie-path if at least one of
the following conditions hold: the following conditions holds:
o The cookie-path and the request-path are identical. o The cookie-path and the request-path are identical.
o The cookie-path is a prefix of the request-path and the last o The cookie-path is a prefix of the request-path, and the last
character of the cookie-path is %x2F ("/"). character of the cookie-path is %x2F ("/").
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 (See responses to "third-party" requests from setting cookies (see
Section 7.1). 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
skipping to change at page 24, line 36 skipping to change at page 20, line 38
Append an attribute to the cookie-attribute-list with an attribute- Append an attribute to the cookie-attribute-list with an attribute-
name of Max-Age and an attribute-value of expiry-time. name of Max-Age and an attribute-value of expiry-time.
5.2.3. The Domain Attribute 5.2.3. The Domain Attribute
If the attribute-name case-insensitively matches the string "Domain", If the attribute-name case-insensitively matches the string "Domain",
the user agent MUST process the cookie-av as follows. the user agent MUST process the cookie-av as follows.
If the attribute-value is empty, the behavior is undefined. However, If the attribute-value is empty, the behavior is undefined. However,
user agent SHOULD ignore the cookie-av entirely. the user agent SHOULD ignore the cookie-av entirely.
If the first character of the attribute-value string is %x2E ("."): If the first character of the attribute-value string is %x2E ("."):
Let cookie-domain be the attribute-value without the leading %x2E Let cookie-domain be the attribute-value without the leading %x2E
(".") character. (".") character.
Otherwise: Otherwise:
Let cookie-domain be the entire attribute-value. Let cookie-domain be the entire attribute-value.
skipping to change at page 27, line 39 skipping to change at page 23, line 41
Otherwise: Otherwise:
Set the cookie's host-only-flag to true. Set the cookie's host-only-flag to true.
Set the cookie's domain to the canonicalized request-host. Set the cookie's domain to the canonicalized request-host.
7. If the cookie-attribute-list contains an attribute with an 7. If the cookie-attribute-list contains an attribute with an
attribute-name of "Path", set the cookie's path to attribute- attribute-name of "Path", set the cookie's path to attribute-
value of the last attribute in the cookie-attribute-list with an value of the last attribute in the cookie-attribute-list with an
attribute-name of "Path". Otherwise, set cookie's path to the attribute-name of "Path". Otherwise, set the cookie's path to
default-path of the request-uri. the default-path of the request-uri.
8. If the cookie-attribute-list contains an attribute with an 8. If the cookie-attribute-list contains an attribute with an
attribute-name of "Secure", set the cookie's secure-only-flag to attribute-name of "Secure", set the cookie's secure-only-flag to
true. Otherwise, set cookie's secure-only-flag to false. true. Otherwise, set the cookie's secure-only-flag to false.
9. If the cookie-attribute-list contains an attribute with an 9. If the cookie-attribute-list contains an attribute with an
attribute-name of "HttpOnly", set the cookie's http-only-flag to attribute-name of "HttpOnly", set the cookie's http-only-flag to
true. Otherwise, set cookie's http-only-flag to false. true. Otherwise, set the cookie's http-only-flag to false.
10. If the cookie was received from a "non-HTTP" API and the 10. If the cookie was received from a "non-HTTP" API and the
cookie's http-only-flag is set, abort these steps and ignore the cookie's http-only-flag is set, abort these steps and ignore the
cookie entirely. cookie entirely.
11. If the cookie store contains a cookie with the same name, 11. If the cookie store contains a cookie with the same name,
domain, and path as the newly created cookie: domain, and path as the newly created cookie:
1. Let old-cookie be the existing cookie with the same name, 1. Let old-cookie be the existing cookie with the same name,
domain, and path as the newly created cookie. (Notice that domain, and path as the newly created cookie. (Notice that
skipping to change at page 28, line 31 skipping to change at page 24, line 35
12. Insert the newly created cookie into the cookie store. 12. Insert the newly created cookie into the cookie store.
A cookie is "expired" if the cookie has an expiry date in the past. A cookie is "expired" if the cookie has an expiry date in the past.
The user agent MUST evict all expired cookies from the cookie store The user agent MUST evict all expired cookies from the cookie store
if, at any time, an expired cookie exists in the cookie store. if, at any time, an expired cookie exists in the cookie store.
At any time, the user agent MAY "remove excess cookies" from the At any time, the user agent MAY "remove excess cookies" from the
cookie store if the number of cookies sharing a domain field exceeds cookie store if the number of cookies sharing a domain field exceeds
some implementation defined upper bound (such as 50 cookies). some implementation-defined upper bound (such as 50 cookies).
At any time, the user agent MAY "remove excess cookies" from the At any time, the user agent MAY "remove excess cookies" from the
cookie store if the cookie store exceeds some predetermined upper cookie store if the cookie store exceeds some predetermined upper
bound (such as 3000 cookies). bound (such as 3000 cookies).
When the user agent removes excess cookies from the cookie store, the When the user agent removes excess cookies from the cookie store, the
user agent MUST evict cookies in the following priority order: user agent MUST evict cookies in the following priority order:
1. Expired cookies. 1. Expired cookies.
skipping to change at page 29, line 15 skipping to change at page 25, line 19
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 from setting cookies (See Section 7.1). "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
meet all of the following requirements: meets all of the following requirements:
* Either: * Either:
The cookie's host-only-flag is true and the canonicalized The cookie's host-only-flag is true and the canonicalized
request-host is identical to the cookie's domain. request-host is identical to the cookie's domain.
Or: Or:
The cookie's host-only-flag is false and the canonicalized The cookie's host-only-flag is false and the canonicalized
request-host domain-matches cookie's domain. request-host domain-matches the cookie's domain.
* The request-uri's path path-matches cookie's path. * The request-uri's path path-matches the cookie's path.
* If the cookie's secure-only-flag is true, then the request- * If the cookie's secure-only-flag is true, then the request-
uri's scheme must denote a "secure" protocol (as defined by uri's scheme must denote a "secure" protocol (as defined by
the user agent). the user agent).
NOTE: The notion of a "secure" protocol is not defined by NOTE: The notion of a "secure" protocol is not defined by
this document. Typically, user agents consider a protocol this document. Typically, user agents consider a protocol
secure if the protocol makes use of transport-layer secure if the protocol makes use of transport-layer
security, such as SSL or TLS. For example, most user security, such as SSL or TLS. For example, most user
agents consider "https" to be a scheme that denotes a agents consider "https" to be a scheme that denotes a
skipping to change at page 30, line 15 skipping to change at page 26, line 18
* If the cookie's http-only-flag is true, then exclude the * If the cookie's http-only-flag is true, then exclude the
cookie if the cookie-string is being generated for a "non- cookie if the cookie-string is being generated for a "non-
HTTP" API (as defined by the user agent). HTTP" API (as defined by the user agent).
2. The user agent SHOULD sort the cookie-list in the following 2. The user agent SHOULD sort the cookie-list in the following
order: order:
* Cookies with longer paths are listed before cookies with * Cookies with longer paths are listed before cookies with
shorter paths. shorter paths.
* Among cookies that have equal length path fields, cookies with * Among cookies that have equal-length path fields, cookies with
earlier creation-times are listed before cookies with later earlier creation-times are listed before cookies with later
creation-times. creation-times.
NOTE: Not all user agents sort the cookie-list in this order, but NOTE: Not all user agents sort the cookie-list in this order, but
this order reflects common practice when this document was this order reflects common practice when this document was
written, and, historically, there have been servers that written, and, historically, there have been servers that
(erroneously) depended on this order. (erroneously) depended on this order.
3. Update the last-access-time of each cookie in the cookie-list to 3. Update the last-access-time of each cookie in the cookie-list to
the current date and time. the current date and time.
skipping to change at page 31, line 30 skipping to change at page 27, line 30
Servers SHOULD use as few and as small cookies as possible to avoid Servers SHOULD use as few and as small cookies as possible to avoid
reaching these implementation limits and to minimize network reaching these implementation limits and to minimize network
bandwidth due to the Cookie header being included in every request. bandwidth due to the Cookie header being included in every request.
Servers SHOULD gracefully degrade if the user agent fails to return Servers SHOULD gracefully degrade if the user agent fails to return
one or more cookies in the Cookie header because the user agent might one or more cookies in the Cookie header because the user agent might
evict any cookie at any time on orders from the user. evict any cookie at any time on orders from the user.
6.2. Application Programming Interfaces 6.2. Application Programming Interfaces
One reason the Cookie and Set-Cookie headers uses such esoteric One reason the Cookie and Set-Cookie headers use such esoteric syntax
syntax is because many platforms (both in servers and user agents) is that many platforms (both in servers and user agents) provide a
provide a string-based application programing interface (API) to string-based application programming interface (API) to cookies,
cookies, requiring application-layer programmers to generate and requiring application-layer programmers to generate and parse the
parse the syntax used by the Cookie and Set-Cookie headers, which syntax used by the Cookie and Set-Cookie headers, which many
many programmers have done incorrectly, resulting in interoperability programmers have done incorrectly, resulting in interoperability
problems. problems.
Instead of providing string-based APIs to cookies, platforms would be Instead of providing string-based APIs to cookies, platforms would be
well-served by providing more semantic APIs. It is beyond the scope well-served by providing more semantic APIs. It is beyond the scope
of this document to recommend specific API designs, but there are of this document to recommend specific API designs, but there are
clear benefits to accepting an abstract "Date" object instead of a clear benefits to accepting an abstract "Date" object instead of a
serialized date string. serialized date string.
6.3. IDNA dependency and migration 6.3. IDNA Dependency and Migration
IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490]. However, there are IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490]. However, there are
differences between the two specifications, and thus there can be differences between the two specifications, and thus there can be
differences in processing (e.g. converting) domain name labels that differences in processing (e.g., converting) domain name labels that
have been registered under one from those registered under the other. have been registered under one from those registered under the other.
There will be a transition period of some time during which IDNA2003- There will be a transition period of some time during which IDNA2003-
based domain name labels will exist in the wild. User agents SHOULD based domain name labels will exist in the wild. User agents SHOULD
implement IDNA2008 [RFC5890] and MAY implement [UTS46] or [RFC5895] implement IDNA2008 [RFC5890] and MAY implement [UTS46] or [RFC5895]
in order to facilitate their IDNA transition. If a user agent does in order to facilitate their IDNA transition. If a user agent does
not implement IDNA2008, the user agent MUST implement IDNA2003 not implement IDNA2008, the user agent MUST implement IDNA2003
[RFC3490]. [RFC3490].
7. Privacy Considerations 7. Privacy Considerations
skipping to change at page 34, line 11 skipping to change at page 29, line 17
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. Some popular user agents expose this functionality via set to false. Some popular user agents expose this functionality via
"private browsing" mode [Aggarwal2010] "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 7.3. Expiration Dates
Although servers can set the expiration date for cookies to the Although servers can set the expiration date for cookies to the
distant future, most user agents do not actually retain cookies for distant future, most user agents do not actually retain cookies for
multiple decades. Rather than chosing gratuitously long expiration multiple decades. Rather than choosing gratuitously long expiration
periods, servers SHOULD promote user privacy by selecting reasonable periods, servers SHOULD promote user privacy by selecting reasonable
cookie expiration periods based on the purpose of the cookie. For cookie expiration periods based on the purpose of the cookie. For
example, a typical session identifier might reasonably be set to example, a typical session identifier might reasonably be set to
expire in two weeks. 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
skipping to change at page 39, line 7 skipping to change at page 33, line 43
cookies. cookies.
8.7. Reliance on DNS 8.7. Reliance on DNS
Cookies rely upon the Domain Name System (DNS) for security. If the Cookies rely upon the Domain Name System (DNS) for security. If the
DNS is partially or fully compromised, the cookie protocol might fail DNS is partially or fully compromised, the cookie protocol might fail
to provide the security properties required by applications. to provide the security properties required by applications.
9. IANA Considerations 9. IANA Considerations
The permanent message header field registry (see [RFC3864]) should be The permanent message header field registry (see [RFC3864]) has been
updated with the following registrations: updated with the following registrations.
9.1. Cookie 9.1. Cookie
Header field name: Cookie Header field name: Cookie
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
skipping to change at page 42, line 5 skipping to change at page 36, line 7
10.2. Informative References 10.2. Informative References
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997. Mechanism", RFC 2109, February 1997.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000. Mechanism", RFC 2965, October 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[Netscape] [Netscape] Netscape Communications Corp., "Persistent Client State --
Netscape Communications Corp., "Persistent Client State --
HTTP Cookies", 1999, <http://web.archive.org/web/ HTTP Cookies", 1999, <http://web.archive.org/web/
20020803110822/http://wp.netscape.com/newsref/std/ 20020803110822/http://wp.netscape.com/newsref/std/
cookie_spec.html>. cookie_spec.html>.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology Vol. 1, Politics", ACM Transactions on Internet Technology Vol. 1,
#2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>. #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
skipping to change at page 42, line 34 skipping to change at page 36, line 35
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for
Internationalized Domain Names in Applications (IDNA) Internationalized Domain Names in Applications (IDNA)
2008", RFC 5895, September 2010. 2008", RFC 5895, September 2010.
[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,
www.adambarth.com/papers/2008/ <http://portal.acm.org/citation.cfm?id=1455770.1455782>.
barth-jackson-mitchell-b.pdf>.
[Aggarwal2010] [Aggarwal2010]
Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh, Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh,
"An Analysis of Private Browsing Modes in Modern "An Analysis of Private Browsing Modes in Modern
Browsers", 2010, <http://www.collinjackson.com/research/ Browsers", 2010, <http://www.usenix.org/events/sec10/tech/
private-browsing.pdf>. full_papers/Aggarwal.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, Alissa Cooper, Bil Corry, to thank Thomas Broyer, Tyler Close, Alissa Cooper, Bil Corry,
corvid, Lisa Dusseault, Roy T. Fielding, Blake Frantz, Anne van corvid, Lisa Dusseault, Roy T. Fielding, Blake Frantz, Anne van
Kesteren, Eran Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim Kesteren, Eran Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim
skipping to change at page 44, line 10 skipping to change at page 37, line 25
Mark Pauley, Yngve N. Pettersen, Julian Reschke, Peter Saint-Andre, Mark Pauley, Yngve N. Pettersen, Julian Reschke, Peter Saint-Andre,
Mark Seaborn, Maciej Stachowiak, Daniel Stenberg, Tatsuhiro Mark Seaborn, Maciej Stachowiak, Daniel Stenberg, Tatsuhiro
Tsujikawa, David Wagner, Dan Winship, and Dan Witte for their Tsujikawa, David Wagner, Dan Winship, and Dan Witte for their
valuable feedback on 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. 52 change blocks. 
152 lines changed or deleted 136 lines changed or added

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