draft-ietf-httpstate-cookie-19.txt   draft-ietf-httpstate-cookie-20.txt 
httpstate A. Barth httpstate A. Barth
Internet-Draft U.C. Berkeley Internet-Draft U.C. Berkeley
Obsoletes: 2965 (if approved) December 3, 2010 Obsoletes: 2965 (if approved) December 19, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: June 6, 2011 Expires: June 22, 2011
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpstate-cookie-19 draft-ietf-httpstate-cookie-20
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 6, 2011. This Internet-Draft will expire on June 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 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) . . . . . . . . . . . . . . 13 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 14
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 17
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 17 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 18
5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 17 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 18
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1.2. Canonicalized host names . . . . . . . . . . . . . . . 19 5.1.2. Canonicalized host names . . . . . . . . . . . . . . . 20
5.1.3. Domain matching . . . . . . . . . . . . . . . . . . . 19 5.1.3. Domain matching . . . . . . . . . . . . . . . . . . . 20
5.1.4. Paths and path-match . . . . . . . . . . . . . . . . . 19 5.1.4. Paths and path-match . . . . . . . . . . . . . . . . . 20
5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 20 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 21
5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 22 5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 23
5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 22 5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 24
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 23 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 24
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 23 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 24
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 24 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 25
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 24 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 25
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 24 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 25
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 27 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 29
6. Implementation Considerations . . . . . . . . . . . . . . . . 30 6. Implementation Considerations . . . . . . . . . . . . . . . . 31
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2. Application Programming Interfaces . . . . . . . . . . . . 30 6.2. Application Programming Interfaces . . . . . . . . . . . . 31
6.3. IDNA dependency and migration . . . . . . . . . . . . . . 30 6.3. IDNA dependency and migration . . . . . . . . . . . . . . 31
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 32 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 33
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 32 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 33
7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 32 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 34 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 35
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 35 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 36
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 35 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 36
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 36 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 37
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 36 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 37
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 37 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 38
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 38 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 38 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 39
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 9.3. Cookie2 . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Normative References . . . . . . . . . . . . . . . . . . . 39 9.4. Set-Cookie2 . . . . . . . . . . . . . . . . . . . . . . . 39
10.2. Informative References . . . . . . . . . . . . . . . . . . 39 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 41 10.1. Normative References . . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 42 10.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 43
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.
skipping to change at page 5, line 35 skipping to change at page 5, line 35
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.
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). This
document attempts to specify the syntax and semantics of these document specifies the syntax and semantics of these headers as they
headers as they are actually used on the Internet. are actually used on the Internet.
In particular, this document does not create new syntax or semantics In particular, this document does not create new syntax or semantics
beyond those in use today, but neither does it recommend all of the beyond those in use today, but neither does it recommend all of the
syntactic and semantic variations in use today. The recommendations syntactic and semantic variations in use today. The recommendations
in this document represent a preferred subset of current behaviors. in this document represent a preferred subset of current behaviors.
Where some existing software differs from the recommended protocol Where some existing software differs from the recommended protocol
in significant ways, the document contains a note explaining the in significant ways, the document contains a note explaining the
difference. difference.
Therefore, in relation to previous IETF specifications of HTTP state Therefore, in relation to previous IETF specifications of HTTP state
skipping to change at page 7, line 32 skipping to change at page 7, line 32
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), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet),
sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US- OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB
ASCII character), VCHAR (any visible US-ASCII character), and WSP (horizontal tab), CHAR (any US-ASCII character), VCHAR (any visible
(whitespace). US-ASCII 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
obs-fold = CRLF obs-fold = CRLF
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.
skipping to change at page 8, line 16 skipping to change at page 8, line 16
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 is receiving an
HTTP response from (i.e., the name of the host to which it sent the HTTP response from (i.e., the name of the host to which it sent the
corresponding HTTP request). 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 octets. The term string means a sequence of non-NUL octets.
3. Overview 3. Overview
This section outlines a way for an origin server to send state This section outlines a way for an origin server to send state
information to a user agent and for the user agent to return the information to a user agent and for the user agent to return the
state information to the origin server. state information to the origin server.
To store state, the origin server includes a Set-Cookie header in an To store state, the origin server includes a Set-Cookie header in an
HTTP response. In subsequent requests, the user agent returns a HTTP response. In subsequent requests, the user agent returns a
Cookie request header to the origin server. The Cookie header Cookie request header to the origin server. The Cookie header
contains cookies the user agent received in previous Set-Cookie contains cookies the user agent received in previous Set-Cookie
headers. The origin server is free to ignore the Cookie header or headers. The origin server is free to ignore the Cookie header or
use its contents for an application-defined purpose. use its contents for an application-defined purpose.
Origin servers can send a Set-Cookie response header with any Origin servers can send a Set-Cookie response header with any
response. An origin server can include multiple Set-Cookie header response. An origin server can include multiple Set-Cookie header
fields in a single response. fields in a single response. The presence of a Cookie or a Set-
Cookie header field does not preclude HTTP caches from storing and
reusing a response.
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into Origin servers SHOULD NOT fold multiple Set-Cookie header fields into
a single header field. The usual mechanism for folding HTTP headers a single header field. The usual mechanism for folding HTTP headers
fields (i.e., as defined in [RFC2616]) might change the semantics of fields (i.e., as defined in [RFC2616]) might change the semantics of
the Set-Cookie header field because the %x2C (",") character is used the Set-Cookie header field because the %x2C (",") character is used
by Set-Cookie in a way that conflicts with such folding. by Set-Cookie in a way that conflicts with such folding.
3.1. Examples 3.1. Examples
Using the Set-Cookie header, a server can send the user agent a short Using the Set-Cookie header, a server can send the user agent a short
skipping to change at page 12, line 29 skipping to change at page 13, line 5
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 /
path-av / secure-av / httponly-av /
extension-av
expires-av = "Expires=" sane-cookie-date
sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
max-age-av = "Max-Age=" non-zero-digit *DIGIT
; In practice, both expires-av and max-age-av are limited
; to dates representable by the user agent.
non-zero-digit = %x31-39
; digits 1 through 9
domain-av = "Domain=" domain-value
domain-value = <subdomain>
; defined in [RFC1034], Section 3.5, as
; enhanced by [RFC1123], Section 2.1
path-av = "Path=" path-value
path-value = <any CHAR except CTLs or ";">
secure-av = "Secure"
httponly-av = "HttpOnly"
extension-av = <any CHAR except CTLs or ";">
cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av /
extension-av
expires-av = "Expires=" sane-cookie-date
sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
max-age-av = "Max-Age=" 1*DIGIT
domain-av = "Domain=" domain-value
domain-value = <subdomain>
; defined in [RFC1034], Section 3.5, as
; enhanced by [RFC1123], Section 2.1
path-av = "Path=" path-value
path-value = <any CHAR except CTLs or ";">
secure-av = "Secure"
httponly-av = "HttpOnly"
extension-av = <any CHAR except CTLs or ";">
Note that some of the grammatical terms above reference documents Note that some of the grammatical terms above reference documents
that use different grammatical notations than this document (which that use different grammatical notations than this document (which
uses ABNF from [RFC5234]). uses ABNF from [RFC5234]).
The semantics of the cookie-value are not defined by this document. The semantics of the cookie-value are not defined by this document.
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 Base 16 [RFC4648]. example, using Base 16 [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. same set-cookie-string. (See Section 5.3 for how user agents handle
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. the same response with the same cookie-name. (See Section 5.2 for
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 represent dates using 32-bit UNIX time_t
skipping to change at page 14, line 44 skipping to change at page 15, line 30
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).
4.1.2.3. The Domain Attribute 4.1.2.3. The Domain Attribute
The Domain attribute specifies those hosts to which the cookie will The Domain attribute specifies those hosts to which the cookie will
be sent. For example, if the value of the Domain attribute is be sent. For example, if the value of the Domain attribute is
"example.com", the user agent will include the cookie in the Cookie "example.com", the user agent will include the cookie in the Cookie
header when making HTTP requests to example.com, www.example.com, and header when making HTTP requests to example.com, www.example.com, and
www.corp.example.com. (Note that a leading %x2E ("."), if present, www.corp.example.com. (Note that a leading %x2E ("."), if present,
is ignored even though that character is not permitted.) If the is ignored even though that character is not permitted, but a
server omits the Domain attribute, the user agent will return the trailing %x2E ("."), if present, will cause the user agent to ignore
cookie only to the origin server. the attribute.) If the server omits the Domain attribute, the user
agent will return the cookie only to the origin server.
WARNING: Some existing user agents treat an absent Domain WARNING: Some existing user agents treat an absent Domain
attribute as if the Domain attribute were present and contained attribute as if the Domain attribute were present and contained
the current host name. For example, if example.com returns a Set- the current host name. For example, if example.com returns a Set-
Cookie header without a Domain attribute, these user agents will Cookie header without a Domain attribute, these user agents will
erroneously send the cookie to www.example.com as well. erroneously send the cookie to www.example.com as well.
The user agent will reject cookies unless the Domain attribute The user agent will reject cookies unless the Domain attribute
specifies a scope for the cookie that would include the origin specifies a scope for the cookie that would include the origin
server. For example, the user agent will accept a cookie with a server. For example, the user agent will accept a cookie with a
skipping to change at page 15, line 39 skipping to change at page 16, line 27
Although seemingly useful for isolating cookies between different Although seemingly useful for isolating cookies between different
paths within a given host, the Path attribute cannot be relied upon paths within a given host, the Path attribute cannot be relied upon
for security (see Section 8). for security (see Section 8).
4.1.2.5. The Secure Attribute 4.1.2.5. The Secure Attribute
The Secure attribute limits the scope of the cookie to "secure" The Secure attribute limits the scope of the cookie to "secure"
channels (where "secure" is defined by the user agent). When a channels (where "secure" is defined by the user agent). When a
cookie has the Secure attribute, the user agent will include the cookie has the Secure attribute, the user agent will include the
cookie in an HTTP request only if the request is transmitted over a cookie in an HTTP request only if the request is transmitted over a
secure channel (typically HTTP over Secure Sockets Layer (SSL), HTTP secure channel (typically HTTP over Transport Layer Security (TLS)
over Transport Layer Security (TLS) [RFC2818], and TLS [RFC5246] [RFC2818]).
itself).
Although seemingly useful for protecting cookies from active network Although seemingly useful for protecting cookies from active network
attackers, the Secure attribute protects only the cookie's attackers, the Secure attribute protects only the cookie's
confidentiality. An active network attacker can overwrite Secure confidentiality. An active network attacker can overwrite Secure
cookies from an insecure channel, disrupting their integrity (see cookies from an insecure channel, disrupting their integrity (see
Section 8.6 for more details). Section 8.6 for more details).
4.1.2.6. The HttpOnly Attribute 4.1.2.6. The HttpOnly Attribute
The HttpOnly attribute limits the scope of the cookie to HTTP The HttpOnly attribute limits the scope of the cookie to HTTP
skipping to change at page 18, line 45 skipping to change at page 19, line 45
* 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,
* the minute-value is greater than 59, or * the minute-value is greater than 59, or
* the second-value is greater than 59. * the second-value is greater than 59.
(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
skipping to change at page 19, line 27 skipping to change at page 20, line 29
this specification). this specification).
3. Concatentate the resulting labels, separated by a %x2E (".") 3. Concatentate 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. o The domain string and the string are identical. (Note that both
the domain string and the string will have been canonicalized to
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).
skipping to change at page 32, line 36 skipping to change at page 33, line 36
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. servers can often track users without using cookies at all by
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.
skipping to change at page 39, line 5 skipping to change at page 39, line 34
Header field name: Set-Cookie Header field name: Set-Cookie
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document: this specification (Section 5.2) Specification document: this specification (Section 5.2)
9.3. Cookie2
Header field name: Cookie2
Applicable protocol: http
Status: obsoleted
Author/Change controller: IETF
Specification document: [RFC2965]
9.4. Set-Cookie2
Header field name: Set-Cookie2
Applicable protocol: http
Status: obsoleted
Author/Change controller: IETF
Specification document: [RFC2965]
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
skipping to change at page 39, line 29 skipping to change at page 41, line 29
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
See Section 6.3 for an explanation why the normative See Section 6.3 for an explanation why the normative
reference to an obsoleted specification is needed. reference to an obsoleted specification is needed.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
Application Protocol Collation Registry", RFC 4790, Application Protocol Collation Registry", RFC 4790,
March 2007. March 2007.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
skipping to change at page 40, line 17 skipping to change at page 42, line 15
[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
10646", STD 63, RFC 3629, November 2003.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[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.
skipping to change at page 41, line 14 skipping to change at page 43, line 14
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, Bil Corry, corvid, Lisa
Dusseault, Roy T. Fielding, Blake Frantz, Anne van Kesteren, Eran Dusseault, Roy T. Fielding, Blake Frantz, Anne van Kesteren, Eran
Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim Hoffmann, Georg Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim Hoffmann, Georg
Koppen, Dean McNamee, Mark Miller, Mark Pauley, Yngve N. Pettersen, Koppen, Dean McNamee, Alexey Melnikov, Mark Miller, Mark Pauley,
Julian Reschke, Peter Saint-Andre, Mark Seaborn, Maciej Stachowiak, Yngve N. Pettersen, Julian Reschke, Peter Saint-Andre, Mark Seaborn,
Daniel Stenberg, Tatsuhiro Tsujikawa, David Wagner, Dan Winship, and Maciej Stachowiak, Daniel Stenberg, Tatsuhiro Tsujikawa, David
Dan Witte for their valuable feedback on this document. Wagner, Dan Winship, and Dan Witte for their 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. 23 change blocks. 
91 lines changed or deleted 130 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/