draft-ietf-httpstate-cookie-09.txt   draft-ietf-httpstate-cookie-10.txt 
httpstate A. Barth httpstate A. Barth
Internet-Draft U.C. Berkeley Internet-Draft U.C. Berkeley
Obsoletes: 2109 (if approved) June 5, 2010 Obsoletes: 2109 (if approved) July 27, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: December 7, 2010 Expires: January 28, 2011
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpstate-cookie-09 draft-ietf-httpstate-cookie-10
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.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
If you have suggestions for improving this document, please send If you have suggestions for improving this document, please send
email to <mailto:http-state@ietf.org>. Suggestions with test cases email to <mailto:http-state@ietf.org>. Suggestions with test cases
are especially appreciated. Further Working Group information is are especially appreciated. Further Working Group information is
available from <https://tools.ietf.org/wg/httpstate/> available from <https://tools.ietf.org/wg/httpstate/>.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 33 skipping to change at page 2, line 33
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 7, 2010. This Internet-Draft will expire on January 28, 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 22 skipping to change at page 3, line 22
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 6 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 6
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 10 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 11
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 11 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 12
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 14 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 15
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 15 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 16
5.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.2. Domains . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.2. Domains and domain-match . . . . . . . . . . . . . . . 18
5.1.3. Paths . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.3. Paths and path-match . . . . . . . . . . . . . . . . . 18
5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 18 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 19
5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 19 5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 21
5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 20 5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 21
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 20 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 22
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 21 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 22
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 21 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 22
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 21 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 23
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 21 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 23
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 25 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 26
6. Implementation Considerations . . . . . . . . . . . . . . . . 27 6. Implementation Considerations . . . . . . . . . . . . . . . . 29
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2. Application Programming Interfaces . . . . . . . . . . . . 27 6.2. Application Programming Interfaces . . . . . . . . . . . . 29
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 30
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 28 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 30
7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 28 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 30 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 30 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 32
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 31 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 33
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 31 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 33
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 32 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 34
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 32 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 34
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 33 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 35
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9.1. Normative References . . . . . . . . . . . . . . . . . . . 34 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.2. Informative References . . . . . . . . . . . . . . . . . . 34 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.1. Normative References . . . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . . 37
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40
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 its surface, cookies have a number of Although simple on its 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 them to the user agent. The scope indicates the cookie when sending them to the user agent. The scope indicates the
maximum amount of time the user agent should return the cookie, the maximum amount of time the user agent should return the cookie, the
servers to which the user agent should return the cookie, and the servers to which the user agent should return the cookie, and the URI
protocols for which the cookie is applicable. 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 provides only confidentiality (not integrity) from active attribute does not provide integrity in the presence of an active
network attackers. Similarly, cookies for a given host are shared network attackers. 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 from policy" used by web browsers isolates content retrieved via different
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 attempts to specify the syntax and semantics of these
headers as they are actually used on the Internet. headers as they are actually used on the Internet.
2. Conventions 2. Conventions
skipping to change at page 7, line 9 skipping to change at page 7, line 9
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 terms request-host and request-uri refer to the values the user The terms request-host and request-uri refer to the values the user
agent would send to the server as, respectively, the host (but not agent would send to the server as, respectively, the host (but not
port) and the absoluteURI (http_URL) of the HTTP Request-Line. port) and the absoluteURI (http_URL) of the HTTP Request-Line.
Two sequence 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].
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 a number of cookies the user agent received in previous Set- contains cookies the user agent received in previous Set-Cookie
Cookie headers. The origin server is free to ignore the Cookie headers. The origin server is free to ignore the Cookie header or
header or use its contents for an application-defined purpose. use its contents for an application-defined purpose.
Servers can send a Set-Cookie response header with any response. An Origin servers can send a Set-Cookie response header with any
origin server can include multiple Set-Cookie header fields in a response. An origin server can include multiple Set-Cookie header
single response. Note that folding multiple Set-Cookie header fields fields in a single response. Note that folding multiple Set-Cookie
into a single header field might change the semantics of the header header fields into a single header field might change the semantics
because the U+002C (",") character is used by the Set-Cookie header of the header because the U+002C (",") character is used by the Set-
in a way that conflicts with such folding. Cookie header 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
string in an HTTP response that the user agent will return in future string in an HTTP response that the user agent will return in future
HTTP requests. For example, the server can send the user agent a HTTP requests. For example, the server can send the user agent a
"session identifier" named SID with the value 31d4d96e407aad42. The "session identifier" named SID with the value 31d4d96e407aad42. The
user agent then returns the session identifier in subsequent user agent then returns the session identifier in subsequent
requests. requests.
skipping to change at page 9, line 8 skipping to change at page 9, line 8
agent to return the cookie to every path and every subdomain of agent to return the cookie to every path and every subdomain of
example.com. example.com.
== Server -> User Agent == == Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com
== User Agent -> Server == == User Agent -> Server ==
Cookie: SID=31d4d96e407aad42 Cookie: SID=31d4d96e407aad42
As shown the next example, the server can store multiple cookies at As shown in the next example, the server can store multiple cookies
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
If the server wishes the user agent to persist the cookie over Notice that the Cookie header above contains two cookies, one named
multiple "sessions," the server can specify an expiration date in the SID and one named lang. If the server wishes the user agent to
Expires attribute. Note that the user agent might delete the cookie persist the cookie over multiple "sessions" (e.g., user agent
before the expiration date if the user agent's cookie store exceeds restarts), the server can specify an expiration date in the Expires
its quota or if the user manually deletes the server's cookie. attribute. Note that the user agent might delete the cookie before
the expiration date if the user agent's cookie store exceeds its
quota or if the user manually deletes the server's cookie.
== Server -> User Agent == == Server -> User Agent ==
Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT
== User Agent -> Server == == User Agent -> Server ==
Cookie: SID=31d4d96e407aad42; lang=en-US Cookie: SID=31d4d96e407aad42; lang=en-US
Finally, to remove a cookie, the server returns a Set-Cookie header Finally, to remove a cookie, the server returns a Set-Cookie header
skipping to change at page 9, line 47 skipping to change at page 10, line 4
Finally, to remove a cookie, the server returns a Set-Cookie header Finally, to remove a cookie, the server returns a Set-Cookie header
with an expiration date in the past. The server will be successful with an expiration date in the past. The server will be successful
in removing the cookie only if the Path and the Domain attribute in in removing the cookie only if the Path and the Domain attribute in
the Set-Cookie header match the values used when the cookie was the Set-Cookie header match the values used when the cookie was
created. created.
== Server -> User Agent == == Server -> User Agent ==
Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT
== User Agent -> Server == == User Agent -> Server ==
Cookie: SID=31d4d96e407aad42 Cookie: SID=31d4d96e407aad42
4. Server Requirements 4. Server Requirements
This section describes the syntax and semantics of a well-behaved This section describes the syntax and semantics of a well-behaved
profile of the Cookie and Set-Cookie headers. Servers SHOULD use the profile of the Cookie and Set-Cookie headers. Servers SHOULD limit
profile described in this section, both to maximize interoperability themselves to the profile described in this section, both to maximize
with existing user agents and because a future version of the Cookie interoperability with existing user agents and because a future
or Set-Cookie headers could remove support for some of the esoteric version of the Cookie or Set-Cookie headers could remove support for
semantics described in the next section. User agents, however, MUST some of the esoteric semantics described in Section 5. User agents,
implement the full semantics to ensure interoperability with servers however, MUST implement the requirements in Section 5 to ensure
making use of the full semantics. interoperability with servers making use of the full semantics.
4.1. Set-Cookie 4.1. Set-Cookie
The Set-Cookie header is used to send cookies from the server to the The Set-Cookie HTTP response header is used to send cookies from 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 [RFC 2616], 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=" 1*DIGIT
domain-av = "Domain=" domain-value
domain-value = <subdomain, defined in [RFC1034], Section 3.5>
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
that use different grammatical notations than this document (which
uses ABNF from [RFC5234]).
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 [RFC 2616], Section 3.3.1>
; Note that RFC 2616 uses a different grammatical
; notation than this document (which uses ABNF
; from [RFC5234]).
max-age-av = "Max-Age=" 1*DIGIT
domain-av = "Domain=" domain-value
domain-value = <subdomain, defined in [RFC 1034], Section 3.5>
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 ";">
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 non-ASCII data in a cookie-value SHOULD encode that data using store non-ASCII data in a cookie-value SHOULD encode that data using
a printable ASCII encoding. a printable ASCII encoding.
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.
Servers SHOULD NOT include more than one Set-Cookie header fields 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.
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 user agents represent dates using 32-bit UNIX time_t NOTE: Some user agents represent dates using 32-bit UNIX time_t
values. Some of these user agents might contain bugs that cause them values. Some of these user agents might contain bugs that cause them
process dates after the year 2038 incorrectly. Servers wishing to to process dates after the year 2038 incorrectly.
interoperate with these user agents might wish to use dates before
2038.
4.1.2. Semantics (Non-Normative) 4.1.2. Semantics (Non-Normative)
This section describes a simplified semantics of the Set-Cookie This section describes a simplified semantics of the Set-Cookie
header. These semantics are detailed enough to be useful for header. These semantics are detailed enough to be useful for
understanding the most common uses of cookies. The full semantics understanding the most common uses of cookies by servers. The full
are described in Section 5. semantics are described in Section 5.
When the user agent receives a Set-Cookie header, the user agent When the user agent receives a Set-Cookie header, the user agent
stores the cookie. Subsequently, when the user agent makes an HTTP stores the cookie together with its attributes. Subsequently, when
request, the user agent includes the applicable, non-expired cookies the user agent makes an HTTP request, the user agent includes the
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 it expires at the end of the returned only to the origin server, and it expires at the end of the
current session (as defined by the user agent). User agents ignore current session (as defined by the user agent). User agents ignore
skipping to change at page 13, line 38 skipping to change at page 14, line 38
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 SSL, HTTP over TLS [RFC2818], and secure channel (typically HTTP over SSL, HTTP over TLS [RFC2818], and
TLS [RFC5246] itself). TLS [RFC5246] 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. cookies from an insecure channel, disrupting their integrity (see
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
requests. In particular, the attribute instructs the user agent to requests. In particular, the attribute instructs the user agent to
omit the cookie when providing access to cookies via "non-HTTP" APIs omit the cookie when providing access to cookies via "non-HTTP" APIs
(such as a web browser API that exposes cookies to scripts). (such as a web browser API that exposes cookies to scripts).
4.2. Cookie 4.2. Cookie
4.2.1. Syntax 4.2.1. Syntax
skipping to change at page 14, line 18 skipping to change at page 15, line 18
Section 4.1 (and the user agent conforms to the requirements in the Section 4.1 (and the user agent conforms to the requirements in the
Section 5), the user agent will send a Cookie header that conforms to Section 5), the user agent will send a Cookie header that conforms to
the following grammar: the following grammar:
cookie-header = "Cookie:" OWS cookie-string OWS cookie-header = "Cookie:" OWS cookie-string OWS
cookie-string = cookie-pair *( ";" SP cookie-pair ) cookie-string = cookie-pair *( ";" SP cookie-pair )
4.2.2. Semantics 4.2.2. Semantics
Each cookie-pair represents a cookie stored by the user agent. The Each cookie-pair represents a cookie stored by the user agent. The
cookie-name and the cookie-value are returned from the corresponding cookie-pair contains the cookie-name and cookie-value the user agent
parts of the Set-Cookie header. received in the Set-Cookie header.
Notice that the cookie attributes are not returned. In particular, Notice that the cookie attributes are not returned. In particular,
the server cannot determine from the Cookie header alone when a the server cannot determine from the Cookie header alone when a
cookie will expire, for which domains the cookie is valid, for which cookie will expire, for which domains the cookie is valid, for which
paths the cookie is valid, or whether the cookie was set with the paths the cookie is valid, or whether the cookie was set with the
Secure or HttpOnly attributes. Secure or HttpOnly attributes.
The semantics of individual cookies in the Cookie header are not The semantics of individual cookies in the Cookie header are not
defined by this document. Servers are expected to imbue these defined by this document. Servers are expected to imbue these
cookies with application-specific semantics. cookies with application-specific semantics.
Although cookies are serialized linearly in the Cookie header, Although cookies are serialized linearly in the Cookie header,
servers SHOULD NOT rely upon the serialization order. In particular, servers SHOULD NOT rely upon the serialization order. In particular,
if the Cookie header contains two cookies with the same name (e.g., if the Cookie header contains two cookies with the same name (e.g.,
with different Path or Domain attributes), servers SHOULD NOT rely that were set with different Path or Domain attributes), servers
upon the order in which these cookies appear in the header. SHOULD NOT rely upon the order in which these cookies appear in the
header.
5. User Agent Requirements 5. User Agent Requirements
For historical reasons, the full semantics of cookies contain a For historical reasons, the full semantics of cookies (as presently
number of exotic quirks. This section is intended to specify the deployed on the Internet) contain a number of exotic quirks. This
Cookie and Set-Cookie headers in sufficient detail to allow a user section is intended to specify the Cookie and Set-Cookie headers in
agent implementing these requirements precisely to interoperate with sufficient detail to allow a user agent implementing these
existing servers. requirements precisely to interoperate with existing servers.
5.1. Algorithms 5.1. Algorithms
This section defines a number of algorithms used by user agents to This section defines a number of algorithms used by user agents to
process the Cookie and Set-Cookie headers. process the Cookie and Set-Cookie headers.
5.1.1. Dates 5.1.1. Dates
The user agent MUST use an algorithm equivalent to the following The user agent MUST use an algorithm equivalent to the following
algorithm to parse a cookie-date: algorithm to parse a cookie-date:
skipping to change at page 17, line 5 skipping to change at page 18, line 5
* the second-value is greater than 59. * the second-value is greater than 59.
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 GMT) are the day-of-month- year, hour, minute, and second (in GMT) 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. Domains 5.1.2. Domains and domain-match
A canonicalized string is the string converted to lower case and A canonicalized string is the string converted to ASCII according to
converted to ASCII according to the IDNA specification [RFC3490]. the IDNA specification [RFC3490] and converted to lower case.
A string domain-matches a cookie-domain 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 cookie-domain and the string are identical. o The domain string and the string are identical.
o All of the following conditions hold: o All of the following conditions hold:
* The cookie-domain 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
cookie-domain is a U+002E (".") character. domain string is a U+002E (".") 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.3. Paths 5.1.3. 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 U+003F ("?") then the uri-path is that path (without the U+003F ("?")
character or query string), and if the request-uri contains a character or query string), and if the request-uri contains a
full absoluteURI, the uri-path is the path component of that URI. full absoluteURI, the uri-path is the path component of that URI.
skipping to change at page 17, line 46 skipping to change at page 18, line 46
2. If the uri-path is empty or if first character of the uri-path is 2. If the uri-path is empty or if first character of the uri-path is
not a U+002F ("/") character, output U+002F ("/") and skip the not a U+002F ("/") character, output U+002F ("/") and skip the
remaining steps. remaining steps.
3. If the uri-path contains only a single U+002F ("/") character, 3. If the uri-path contains only a single U+002F ("/") character,
output U+002F ("/") and skip the remaining steps. output U+002F ("/") and skip the remaining steps.
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 U+002F ("/"). to, but not including, the right-most U+002F ("/").
A request-path path-matches a cookie-path if at least one of the A request-path path-matches a given cookie-path if at least one of
following conditions hold: the following conditions hold:
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 U+002F ("/"). character of the cookie-path is U+002F ("/").
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 U+002F ("/") character. path is a U+002F ("/") 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 receives a set-cookie-string consisting of response, the user agent MUST parse the field-value of the Set-Cookie
the contents of the header field. header field as a set-cookie-string (defined below).
NOTE: The algorithm below is more permissive than the grammar in
Section 4.1. For example, the algorithm strips leading and trailing
whitespace from the cookie name and value (but maintains internal
whitespace), whereas the grammar in Section 4.1 forbids whitespace in
these positions. User agents use this algorithm so as to
interoperate with servers that do not follow the recommendations in
Section 4.
A user agent MUST use an algorithm equivalent to the following A user agent MUST use an algorithm equivalent to the following
algorithm to parse set-cookie-strings: algorithm to parse a "set-cookie-string":
1. If the set-cookie-string contains a U+003B (";") character: 1. If the set-cookie-string contains a U+003B (";") character:
The name-value-pair string consists of the characters up to, The name-value-pair string consists of the characters up to,
but not including, the first U+003B (";"), and the unparsed- but not including, the first U+003B (";"), and the unparsed-
attributes consist of the remainder of the set-cookie-string attributes consist of the remainder of the set-cookie-string
(including the U+003B (";") in question). (including the U+003B (";") in question).
Otherwise: Otherwise:
skipping to change at page 19, line 40 skipping to change at page 20, line 49
The attribute-name string consists of the entire cookie-av The attribute-name string consists of the entire cookie-av
string, and the attribute-value string is empty. string, and the attribute-value string is empty.
5. Remove any leading or trailing WSP characters from the attribute- 5. Remove any leading or trailing WSP characters from the attribute-
name string and the attribute-value string. name string and the attribute-value string.
6. Process the attribute-name and attribute-value according to the 6. Process the attribute-name and attribute-value according to the
requirements in the following subsections. (Notice that requirements in the following subsections. (Notice that
attributes with unrecognized attribute-names are ignored.) attributes with unrecognized attribute-names are ignored.)
7. Return to Step 1. 7. Return to Step 1 of this algorithm.
When the user agent finishes parsing the set-cookie-string, the user When the user agent finishes parsing the set-cookie-string, the user
agent receives a cookie from the request-uri with name cookie-name, agent is said to "receive a cookie" from the request-uri with name
value cookie-value, and attributes cookie-attribute-list. cookie-name, value cookie-value, and attributes cookie-attribute-
list. (See Section 5.3 for additional requirements triggered by
receiving a cookie.)
5.2.1. The Expires Attribute 5.2.1. The Expires Attribute
If the attribute-name case-insensitively matches the string If the attribute-name case-insensitively matches the string
"Expires", the user agent MUST process the cookie-av as follows. "Expires", the user agent MUST process the cookie-av as follows.
Let the expiry-time be the result of parsing the attribute-value as Let the expiry-time be the result of parsing the attribute-value as
cookie-date (see Section 5.1.1). cookie-date (see Section 5.1.1).
If the attribute-value failed to parse as a cookie date, ignore the If the attribute-value failed to parse as a cookie date, ignore the
skipping to change at page 21, line 49 skipping to change at page 23, line 19
attribute-list with an attribute-name of HttpOnly and an empty attribute-list with an attribute-name of HttpOnly and an empty
attribute-value. attribute-value.
5.3. Storage Model 5.3. Storage Model
The user agent stores the following fields about each cookie: name, The user agent stores the following fields about each cookie: name,
value, expiry-time, domain, path, creation-time, last-access-time, value, expiry-time, domain, path, creation-time, last-access-time,
persistent-flag, host-only-flag, secure-only-flag, and http-only- persistent-flag, host-only-flag, secure-only-flag, and http-only-
flag. flag.
When the user agent receives a cookie from a request-uri with name When the user agent "receives a cookie" from a request-uri with name
cookie-name, value cookie-value, and attributes cookie-attribute- cookie-name, value cookie-value, and attributes cookie-attribute-
list, the user agent MUST process the cookie as follows: list, the user agent MUST process the cookie as follows:
1. A user agent MAY ignore a received cookie in its entirety. For 1. A user agent MAY ignore a received cookie in its entirety. For
example, the user agent might wish to block receiving cookies example, the user agent might wish to block receiving cookies
from "third-party" responses or the user agent might not wish to from "third-party" responses or the user agent might not wish to
store cookies that exceed some size. store cookies that exceed some size.
2. Create a new cookie with name cookie-name, value cookie-value. 2. Create a new cookie with name cookie-name, value cookie-value.
Set the creation-time and the last-access-time to the current Set the creation-time and the last-access-time to the current
skipping to change at page 24, line 9 skipping to change at page 25, line 25
default-path of the request-uri. 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 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 cookie's http-only-flag to false.
10. If the cookie was received from a non-HTTP API and the cookie's 10. If the cookie was received from a "non-HTTP" API and the
http-only-flag is set, abort these steps and ignore the cookie cookie's http-only-flag is set, abort these steps and ignore the
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
this algorithm maintains the invariant that there is at most this algorithm maintains the invariant that there is at most
one such cookie.) one such cookie.)
2. If the newly created cookie was received from an non-HTTP 2. If the newly created cookie was received from an "non-HTTP"
API and the old-cookie's http-only-flag is set, abort these API and the old-cookie's http-only-flag is set, abort these
steps and ignore the newly created cookie entirely. steps and ignore the newly created cookie entirely.
3. Update the creation-time of the newly created cookie to 3. Update the creation-time of the newly created cookie to
match the creation-time of the old-cookie. match the creation-time of the old-cookie.
4. Remove the old-cookie from the cookie store. 4. Remove the old-cookie from the cookie store.
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 predetermined upper bound (such as 50 cookies). some implementaiton 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 25, line 16 skipping to change at page 26, line 32
If two cookies have the same removal priority, the user agent MUST If two cookies have the same removal priority, the user agent MUST
evict the cookie with the earliest last-access date first. evict the cookie with the earliest last-access date first.
When "the current session is over" (as defined by the user agent), When "the current session is over" (as defined by the user agent),
the user agent MUST remove from the cookie store all cookies with the the user agent MUST remove from the cookie store all cookies with the
persistent-flag set to false. persistent-flag set to false.
5.4. The Cookie Header 5.4. The Cookie Header
When the user agent generates an HTTP request, the user agent SHOULD The user agent includes stored cookies in the Cookie HTTP request
attach exactly one HTTP header named Cookie if the cookie-string header.
(defined below) for the request-uri is non-empty.
When the user agent generates an HTTP request, the user agent MUST
NOT attach more than one Cookie header field.
A user agent MAY omit the Cookie header in its entirety. For A user agent MAY omit the Cookie header in its entirety. For
example, the user agent might wish to block sending cookies during example, the user agent might wish to block sending cookies during
"third-party" requests. "third-party" requests.
If the user agent does attach a Cookie header field to an HTTP
request, the user agent MUST send the cookie-string (defined below)
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: meet 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.
skipping to change at page 26, line 6 skipping to change at page 27, line 29
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
secure protocol. secure protocol.
* 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 unless the cookie-string is being generated for an 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.
skipping to change at page 26, line 39 skipping to change at page 28, line 14
1. Output the cookie's name, the U+003D ("=") character, and the 1. Output the cookie's name, the U+003D ("=") character, and the
cookie's value. cookie's value.
2. If there is an unprocessed cookie in the cookie-list, output 2. If there is an unprocessed cookie in the cookie-list, output
the characters U+003B and U+0020 ("; "). the characters U+003B and U+0020 ("; ").
NOTE: Despite its name, the cookie-string is actually a sequence of NOTE: Despite its name, the cookie-string is actually a sequence of
octets, not a sequence of characters. To convert the cookie-string octets, not a sequence of characters. To convert the cookie-string
(or components thereof) into a sequence of characters (e.g., for (or components thereof) into a sequence of characters (e.g., for
presentation to the user), the user agent SHOULD use the UTF-8 presentation to the user), the user agent might wish use the UTF-8
character encoding [RFC3629]. character encoding [RFC3629] to decode the octet sequence.
6. Implementation Considerations 6. Implementation Considerations
6.1. Limits 6.1. Limits
Practical user agent implementations have limits on the number and Practical user agent implementations have limits on the number and
size of cookies that they can store. General-use user agents SHOULD size of cookies that they can store. General-use user agents SHOULD
provide each of the following minimum capabilities: provide each of the following minimum capabilities:
o At least 4096 bytes per cookie (as measured by the sum of the o At least 4096 bytes per cookie (as measured by the sum of the
skipping to change at page 27, line 32 skipping to change at page 29, line 32
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 uses such esoteric
syntax is because many platforms (both in servers and user agents) syntax is because many platforms (both in servers and user agents)
provide a string-based application programmer interface (API) to provide a string-based application programing interface (API) to
cookies, requiring application-layer programmers to generate and cookies, requiring application-layer programmers to generate and
parse the syntax used by the Cookie and Set-Cookie headers, which parse the syntax used by the Cookie and Set-Cookie headers, which
many programmers have done incorrectly, resulting in interoperability many 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.
skipping to change at page 34, line 5 skipping to change at page 36, line 5
reaches its storage limit, the user agent will be forced to evict reaches its storage limit, the user agent will be forced to evict
some cookies. Servers SHOULD NOT rely upon user agents retaining some cookies. Servers SHOULD NOT rely upon user agents retaining
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. References 9. IANA Considerations
9.1. Normative References The permanent message header registry (see [RFC3864]) should be
updated with the following registrations:
9.1. Cookie
Header field name: Cookie
Applicable protocol: http
Status: standard
Author/Change controller: IETF
Specification document: this specification (Section 5.4)
9.2. Set-Cookie
Header field name: Set-Cookie
Applicable protocol: http
Status: standard
Author/Change controller: IETF
Specification document: this specification (Section 5.2)
10. 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
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.
skipping to change at page 34, line 36 skipping to change at page 37, line 36
[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.
9.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]
"Persistent Client State -- HTTP Cookies". "Persistent Client State -- HTTP Cookies".
[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>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
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 the cookie protocol. David M. Kristol, in particular, specify cookies. David M. Kristol, in particular, provided
provided invaluable advice on navigating the IETF process. We would invaluable advice on navigating the IETF process. We would also like
also like to thank Thomas Broyer, Tyler Close, Bil Corry, corvid, to thank Thomas Broyer, Tyler Close, Bil Corry, corvid, Lisa
Lisa Dusseault, Roy T. Fielding, Blake Frantz, Eran Hammer-Lahav, Dusseault, Roy T. Fielding, Blake Frantz, Anne van Kesteren, Eran
Jeff Hodges, Bjoern Hoehrmann, Achim Hoffmann, Georg Koppen, Dean Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim Hoffmann, Georg
McNamee, Mark Miller, Mark Pauley, Yngve N. Pettersen, Julian Koppen, Dean McNamee, Mark Miller, Mark Pauley, Yngve N. Pettersen,
Reschke, Peter Saint-Andre, Mark Seaborn, Maciej Stachowiak, Daniel Julian Reschke, Peter Saint-Andre, Mark Seaborn, Maciej Stachowiak,
Stenberg, David Wagner, Dan Winship, and Dan Witte for their valuable Daniel Stenberg, David Wagner, Dan Winship, and Dan Witte for their
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. 55 change blocks. 
162 lines changed or deleted 217 lines changed or added

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