draft-ietf-httpstate-cookie-01.txt   draft-ietf-httpstate-cookie-02.txt 
httpstate A. Barth httpstate A. Barth
Internet-Draft U.C. Berkeley Internet-Draft U.C. Berkeley
Obsoletes: 2109 (if approved) January 6, 2010 Obsoletes: 2109 (if approved) January 21, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: July 10, 2010 Expires: July 25, 2010
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpstate-cookie-01 draft-ietf-httpstate-cookie-02
Abstract
This document defines the HTTP Cookie and Set-Cookie headers. These
headers can be used by HTTP servers to store state on HTTP user
agents, letting the servers maintain a stateful session over the
mostly stateless HTTP protocol. The cookie protocol has many
historical infelicities and should be avoided for new applications of
HTTP.
NOTE: If you have suggestions for improving the draft, please send
email to http-state@ietf.org. Suggestions with test cases are
especially appreciated.
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. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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.
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."
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 July 10, 2010. This Internet-Draft will expire on July 25, 2010.
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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document defines the HTTP Cookie and Set-Cookie headers. These described in the BSD License.
headers can be used by HTTP servers to store state on HTTP user
agents, letting the servers maintain a stateful session over the
mostly stateless HTTP protocol. The cookie protocol has many
historical infelicities and should be avoided for new applications of
HTTP.
NOTE: If you have suggestions for improving the draft, please send This document may contain material from IETF Documents or IETF
email to http-state@ietf.org. Suggestions with test cases are Contributions published or made publicly available before November
especially appreciated. 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.1. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. A Well-Behaved Profile . . . . . . . . . . . . . . . . . . . . 8 4. A Well-Behaved Profile . . . . . . . . . . . . . . . . . . . . 7
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 9 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 8
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 11 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 10
5. The Cookie Protocol . . . . . . . . . . . . . . . . . . . . . 12 5. The Cookie Protocol . . . . . . . . . . . . . . . . . . . . . 11
5.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.2. Domains . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.2. Domains . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.3. Paths . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.3. Paths . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 15 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 14
5.2.1. The Max-Age Attribute . . . . . . . . . . . . . . . . 17 5.2.1. The Max-Age Attribute . . . . . . . . . . . . . . . . 16
5.2.2. The Expires Attribute . . . . . . . . . . . . . . . . 17 5.2.2. The Expires Attribute . . . . . . . . . . . . . . . . 16
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 18 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 17
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 18 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 17
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 19 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 18
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 19 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 18
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 19 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 18
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 21 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 21
6. Implementation Limits . . . . . . . . . . . . . . . . . . . . 24 6. Implementation Limits . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 25 7.1. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 25 7.2. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 24
7.3. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 25 7.3. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 24
8. Normative References . . . . . . . . . . . . . . . . . . . . . 27 8. Normative References . . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
This document defines the HTTP Cookie and Set-Cookie header. Using This document defines the HTTP Cookie and Set-Cookie header. Using
the Set-Cookie header, an HTTP server can store name/value pairs the Set-Cookie header, an HTTP server can store name/value pairs and
(called cookies) at the user agent. When the user agent makes associated metadata (called cookies) at the user agent. When the
subsequent requests to the server, the user agent will return the user agent makes subsequent requests to the server, the user agent
name/value pairs in the Cookie header. uses the metadata to determine whether to return the name/value pairs
in the Cookie header.
Although simple on its surface, the cookie protocol has a number of Although simple on its surface, the cookie protocol has 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 persist the cookie, to maximum amount of time the user agent should retain the cookie, to
which servers the user agent should return the cookie, and for which which servers the user agent should return the cookie, and for which
protocols the cookie is applicable. protocols the cookie is applicable.
For historical reasons, the cookie protocol contains a number of For historical reasons, the cookie protocol contains a number of
security and privacy infelicities. For example, a server can security and privacy infelicities. For example, a server can
indicate that a given cookie is intended for "secure" connections, indicate that a given cookie is intended for "secure" connections,
but the Secure attribute provides only confidentiality (not but the Secure attribute provides only confidentiality (not
integrity) from active network attackers. Similarly, cookies for a integrity) from active network attackers. Similarly, cookies for a
given host are shared across all the ports on that host, even though given host are shared across all the ports on that host, even though
the usual "same-origin policy" used by web browsers isolates content the usual "same-origin policy" used by web browsers isolates content
skipping to change at page 6, line 8 skipping to change at page 5, line 8
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), OCTET (any 8-bit
sequence of data), SP (space), HTAB (horizontal tab), VCHAR (any sequence of data), SP (space), HTAB (horizontal tab), VCHAR (any
visible [USASCII] character), and WSP (whitespace). visible [USASCII] character), and WSP (whitespace).
2. Terminology 2. 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.0 specification. the same meaning as in the HTTP/1.1 specification.
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 abs_path portions of the absoluteURI (http_URL) of the HTTP port) and abs_path portions of the absoluteURI (http_URL) of the HTTP
request line. Request-Line.
3. Overview 3. Overview
We outline here a way for an origin server to send state information We outline here a way for an origin server to send state information
to the user agent, and for the user agent to return the state to a user agent, and for the user agent to return the state
information to the origin server. information to the origin server.
The origin server initiates a session, if it so desires, by including To initiate a session, the origin server includes a Set-Cookie header
a Set-Cookie header in an HTTP response. (Note that "session" here in an HTTP response. (Note that "session" here does not refer to a
does not refer to a persistent network connection but to a logical persistent network connection but to a logical session created from
session created from HTTP requests and responses. The presence or HTTP requests and responses. The presence or absence of a persistent
absence of a persistent connection should have no effect on the use connection should have no effect on the use of cookie-derived
of cookie-derived sessions). sessions).
The user agent returns a Cookie request header to the origin server The user agent returns a Cookie request header to the origin server
if it chooses to continue a session. The Cookie header contains a if it chooses to continue a session. The Cookie header contains a
number of cookies the user agent received in previous Set-Cookie number of cookies the user agent received in previous Set-Cookie
headers. The origin server MAY ignore the Cookie header or use the headers. The origin server MAY ignore the Cookie header or use the
header to determine the current state of the session. The origin header to determine the current state of the session. The origin
server MAY send the user agent a Set-Cookie response header with the server MAY send the user agent a Set-Cookie response header with the
same or different information, or it MAY send no Set-Cookie header at same or different information, or it MAY send no Set-Cookie header at
all. all.
Servers MAY return a Set-Cookie response headers with any response. Servers MAY return a Set-Cookie response header with any response.
User agents should send Cookie request headers, subject to other User agents SHOULD send a Cookie request header, subject to other
rules detailed below, with every request. rules detailed below, with every request.
An origin server MAY include multiple Set-Cookie header fields in a An origin server MAY include multiple Set-Cookie header fields in a
single response. Note that an intervening gateway MUST NOT fold single response. Note that an intervening gateway MUST NOT fold
multiple Set-Cookie header fields into a single header field. multiple Set-Cookie header fields into a single header field.
3.1. Examples 3.1. Examples
[TODO: Put some examples here. [TODO: Put some examples here.
skipping to change at page 8, line 29 skipping to change at page 7, line 29
4.1.1. Syntax 4.1.1. Syntax
Informally, the Set-Cookie response header comprises the token Set- Informally, the Set-Cookie response header comprises the token Set-
Cookie:, followed by a cookie. Each cookie begins with a name-value- Cookie:, followed by a cookie. Each cookie begins with a name-value-
pair, followed by zero or more attribute-value pairs. Servers SHOULD pair, followed by zero or more attribute-value pairs. Servers SHOULD
NOT send Set-Cookie headers that fail to conform to the following NOT send Set-Cookie headers that fail to conform to the following
grammar: grammar:
set-cookie-header = "Set-Cookie:" OWS set-cookie-string OWS set-cookie-header = "Set-Cookie:" OWS set-cookie-string OWS
set-cookie-string = cookie-pair *( ";" cookie-av) set-cookie-string = cookie-pair *( ";" 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, as defined in RFC 2616> token = <token, as defined in RFC 2616>
cookie-av = expires-av / domain-av / path-av / cookie-av = expires-av / domain-av / path-av /
secure-av / httponly-av secure-av / httponly-av
expires-av = "Expires" "=" cookie-date expires-av = "Expires" "=" cookie-date
cookie-date = <rfc1123-date, as defined in RFC 2616> cookie-date = <rfc1123-date, as defined in RFC 2616>
domain-av = "Domain" "=" domain-value domain-av = "Domain" "=" domain-value
skipping to change at page 9, line 46 skipping to change at page 8, line 46
The Expires attribute indicates the maximum lifetime of the cookie, The Expires attribute indicates the maximum lifetime of the cookie,
represented as the date and time at which the cookie expires. The represented as the date and time at which the cookie expires. The
user agent is not required to retain the cookie until the specified user agent is not required to retain the cookie until the specified
date has passed. In fact, user agents often evict cookies from the date has passed. In fact, user agents often evict cookies from the
cookie store due to memory pressure or privacy concerns. cookie store due to memory pressure or privacy concerns.
4.1.2.2. Domain 4.1.2.2. Domain
The Domain attribute specifies those hosts for which the cookie will The Domain attribute specifies those hosts for which the cookie will
be sent. For example, if the domain attribute contains the value be sent. For example, if the Domain attribute contains the value
".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 U+2E ("."), if present, www.corp.example.com. (Note that a leading U+002E ("."), if present,
is ignored.) If the server omits the Domain attribute, the user is ignored.) If the server omits the Domain attribute, the user
agent will return the cookie only to the origin server agent will return the cookie only to the origin server.
The user agent will reject cookies (refuse to store them in the The user agent will reject cookies (refuse to store them in the
cookie store) unless the Domain attribute specifies a scope for the cookie store) unless the Domain attribute specifies a scope for the
cookie that would include the origin server. For example, the user cookie that would include the origin server. For example, the user
agent will accept a Domain attribute of ".example.com" or of agent will accept a Domain attribute of ".example.com" or of
".foo.example.com" from foo.example.com, but the user agent will not ".foo.example.com" from foo.example.com, but the user agent will not
accept a Domain attribute of ".bar.example.com" or of accept a Domain attribute of ".bar.example.com" or of
".baz.foo.example.com". ".baz.foo.example.com".
NOTE: For security reasons, some user agents are configured to reject NOTE: For security reasons, some user agents are configured to reject
Domain attributes that do not correspond to a "registry controlled" Domain attributes that do not correspond to a "registry controlled"
skipping to change at page 11, line 20 skipping to change at page 10, line 20
HTTP" APIs (as defined by the user agent). HTTP" APIs (as defined by the user agent).
4.2. Cookie 4.2. Cookie
4.2.1. Syntax 4.2.1. Syntax
The user agent returns stored cookies to the origin server in the The user agent returns stored cookies to the origin server in the
Cookie header. If the server conforms to the requirements in this Cookie header. If the server conforms to the requirements in this
section, the requirements in the next section will cause the user section, the requirements in the next section will cause the user
agent to return a Cookie header that conforms to the following agent to return a Cookie header that conforms to the following
grammar. grammar:
cookie-header = "Cookie:" OWS cookie-string OWS cookie-header = "Cookie:" OWS cookie-string OWS
cookie-string = cookie-pair *( ";" cookie-pair) cookie-string = cookie-pair *( ";" cookie-pair )
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, as defined in Section 2.2 of RFC 2616> token = <token, as defined in Section 2.2 of RFC 2616>
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 verbatim from the cookie-name and the cookie-value are returned verbatim from the
corresponding parts of the Set-Cookie header. corresponding parts of the Set-Cookie header.
skipping to change at page 12, line 13 skipping to change at page 11, line 13
cookies with server-specific semantics. cookies with server-specific semantics.
5. The Cookie Protocol 5. The Cookie Protocol
For historical reasons, the full cookie protocol contains a number of For historical reasons, the full cookie protocol contains a number of
exotic quirks. This section is intended to specify the cookie exotic quirks. This section is intended to specify the cookie
protocol in enough detail to enable a user agent that implements the protocol in enough detail to enable a user agent that implements the
protocol precisely as specified to interoperate with existing protocol precisely as specified to interoperate with existing
servers. servers.
Although some parts of the cookie protocol are specified Conformance requirements phrased as algorithms or specific steps may
algorithmically, user agents are free to implement the cookie be implemented in any manner, so long as the end result is
protocol in any manner as long as their resultant behavior is "black- equivalent. (In particular, the algorithms defined in this
box" indistinguishable from a user agent that implements the protocol specification are intended to be easy to follow, and not intended to
as described. be performant.)
5.1. Algorithms 5.1. Algorithms
This section defines a number of algorithms used by the cookie This section defines a number of algorithms used by the cookie
protocol. protocol.
5.1.1. Dates 5.1.1. Dates
The user agent MUST use the following algorithm to *parse a cookie- The user agent MUST use the following algorithm to *parse a cookie-
date*: date*:
1. Using the grammar below, divide the cookie-date into date-tokens. 1. Using the grammar below, divide the cookie-date into date-tokens.
cookie-date = date-token *( 1*delimiter date-token ) cookie-date = *delimiter date-token-list *delimiter
date-token-list = date-token *( 1*delimiter date-token )
delimiter = %x09 / %x20 / %x21 / %x22 / %x23 / %x24 / delimiter = %x09 / %x20 / %x21 / %x22 / %x23 / %x24 /
%x25 / %x26 / %x27 / %x28 / %x29 / %x2A / %x25 / %x26 / %x27 / %x28 / %x29 / %x2A /
%x2B / %x2C / %x2D / %x2E / %x2F / %x3B / %x2B / %x2C / %x2D / %x2E / %x2F / %x3B /
%x3C / %x3D / %x3E / %x3F / %x40 / %x5B / %x3C / %x3D / %x3E / %x3F / %x40 / %x5B /
%x5C / %x5D / %x5E / %x5F / %x60 / %x7B / %x5C / %x5D / %x5E / %x5F / %x60 / %x7B /
%x7C / %x7D / %x7E %x7C / %x7D / %x7E
date-token = day-of-month / month / year / time / mystery date-token = day-of-month / month / year / time / mystery
day-of-month = 2DIGIT / DIGIT day-of-month = 2DIGIT / DIGIT
month = "jan" [ mystery ] / "feb" [ mystery ] / month = "jan" [ mystery ] / "feb" [ mystery ] /
"mar" [ mystery ] / "apr" [ mystery ] / "mar" [ mystery ] / "apr" [ mystery ] /
skipping to change at page 15, line 8 skipping to change at page 14, line 8
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 an Set-Cookie header in an HTTP response, When a user agent receives a Set-Cookie header in an HTTP response,
the user agent *receives a set-cookie-string* consisting of the value the user agent *receives a set-cookie-string* consisting of the value
of the header. of the header.
A user agent MUST use the following algorithm to parse set-cookie- A user agent MUST use the following algorithm to parse set-cookie-
strings: strings:
1. If the set-cookie-string is empty or consists entirely of WSP 1. If the set-cookie-string is empty or consists entirely of WSP
characters, the user agent MAY ignore the set-cookie-string characters, the user agent MAY ignore the set-cookie-string
entirely. entirely.
2. If the set-cookie-string contains a U+003B (";") character: 2. 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:
The name-value-pair string consists of all the character The name-value-pair string consists of all the characters
contained in the set-cookie-string, and the unparsed- contained in the set-cookie-string, and the unparsed-
attributes is the empty string. attributes is the empty string.
3. If the name-value-pair string contains a U+003D ("=") character: 3. If the name-value-pair string contains a U+003D ("=") character:
The (possibly empty) name string consists of the characters up The (possibly empty) name string consists of the characters up
to, but not including, the first U+003D ("=") character, and to, but not including, the first U+003D ("=") character, and
the (possibly empty) value string consists of the characters the (possibly empty) value string consists of the characters
after the first U+003D ("=") character. after the first U+003D ("=") character.
skipping to change at page 20, line 27 skipping to change at page 19, line 27
3. If the cookie-attribute-list contains an attribute with an 3. If the cookie-attribute-list contains an attribute with an
attribute-name of "Domain": attribute-name of "Domain":
Let the domain-attribute be the attribute-value of the last Let the domain-attribute be the attribute-value of the last
attribute in the cookie-attribute-list with an attribute-name attribute in the cookie-attribute-list with an attribute-name
of "Domain". of "Domain".
If the Request-URI's host does not domain-match the domain- If the Request-URI's host does not domain-match the domain-
attribute, ignore the cookie entirely and abort these steps. attribute, ignore the cookie entirely and abort these steps.
If the user agent is configured to use a "public suffix" list
and the domain-attribute is a public suffix, ignore the
cookie entirely and abort these steps.
NOTE: A "public suffix" is a domain that is controlled by
a public registry, such as "com", "co.uk", and
"pvt.k12.wy.us". This step is essential for preventing
attacker.com from disrupting the integrity of example.com
by setting a cookie with a Domain attribute of "com".
Unfortunately, the set of public suffixes (also known as
"registry controlled domains") changes over time. If
feasible, user agents SHOULD use an up-to-date public
suffix list, such as the one maintained by the Mozilla
project at http://publicsuffix.org/.
Set the cookie's host-only-flag to false. Set the cookie's host-only-flag to false.
Set the cookie's domain to the domain-attribute. Set the cookie's domain to the domain-attribute.
Otherwise: Otherwise:
Set the cookie's host-only-flag to true. Set the cookie's host-only-flag to true.
Set the cookie's domain to the host of the Request-URI. Set the cookie's domain to the host of the Request-URI.
skipping to change at page 22, line 28 skipping to change at page 21, line 45
The cookie's host-only-flag is false and the request-host The cookie's host-only-flag is false and the request-host
domain-matches cookie's domain. domain-matches cookie's domain.
* The Request-URI's path patch-matches cookie's path. * The Request-URI's path patch-matches cookie's path.
* If the cookie's secure-only field is true, then the Request- * If the cookie's secure-only field is true, then the Request-
URI's scheme must denote a "secure" protocol (as defined by URI's scheme must denote a "secure" protocol (as defined by
the user agent). the user agent).
NOTE: The notion of an "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 TLS. For example, most user agents security, such as TLS. For example, most user agents
consider "https" to be a scheme that denotes a secure consider "https" to be a scheme that denotes a secure
protocol. protocol.
* If the cookie's http-only field is true, then exclude the * If the cookie's http-only field is true, then exclude the
cookie unless the cookie-string is begin generated for a cookie unless the cookie-string is being generated for an
"HTTP" API (as defined by the user agent). "HTTP" API (as defined by the user agent).
2. Sort the cookie-list in the following order: 2. Sort the cookie-list in the following 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 25, line 25 skipping to change at page 24, line 25
2. A malicious intermediary could alter the headers as they travel 2. A malicious intermediary could alter the headers as they travel
in either direction, with unpredictable results. in either direction, with unpredictable results.
3. A malicious client could alter the Cookie header before 3. A malicious client could alter the Cookie header before
transmission, with unpredictable results. transmission, with unpredictable results.
Servers SHOULD encrypt and sign their cookies. However, encrypting Servers SHOULD encrypt and sign their cookies. However, encrypting
and signing cookies does not prevent an attacker from transplanting a and signing cookies does not prevent an attacker from transplanting a
cookie from one user agent to another. cookie from one user agent to another.
In addition to encrypting and signing the the contents of every In addition to encrypting and signing the contents of every cookie,
cookie, servers that require a higher level of security SHOULD use servers that require a higher level of security SHOULD use the cookie
the cookie protocol only over a secure channel. protocol only over a secure channel.
7.2. Weak Confidentiality 7.2. Weak Confidentiality
Cookies do provide isolation by port. If a cookie is readable by a Cookies do not provide isolation by port. If a cookie is readable by
service running on one port, the cookie is also readable by a service a service running on one port, the cookie is also readable by a
running on another port of the same server. If a cookie is writable service running on another port of the same server. If a cookie is
by a service on one port, the cookie is also writable by a service writable by a service on one port, the cookie is also writable by a
running on another port of the same server. For this reason, servers service running on another port of the same server. For this reason,
SHOULD NOT both run mutually distrusting services on different ports servers SHOULD NOT both run mutually distrusting services on
of the same machine and use cookies to store security-sensitive different ports of the same machine and use cookies to store
information. security-sensitive information.
Cookies do not provide isolation by scheme. Although most commonly Cookies do not provide isolation by scheme. Although most commonly
used with the http and https schemes, the cookies for a given host used with the http and https schemes, the cookies for a given host
are also available to other schemes, such as ftp and gopher. This are also available to other schemes, such as ftp and gopher. This
lack of isolation is most easily seen when a user agent retrieves a lack of isolation is most easily seen when a user agent retrieves a
URI with a gopher scheme via HTTP, but the lack of isolation by URI with a gopher scheme via HTTP, but the lack of isolation by
scheme is also apparent via non-HTTP APIs that permit access to scheme is also apparent via non-HTTP APIs that permit access to
cookies, such as HTML's document.cookie API. cookies, such as HTML's document.cookie API.
7.3. Weak Integrity 7.3. Weak Integrity
Cookies do not integrity guarantees for sibling domains (and their Cookies do not provide integrity guarantees for sibling domains (and
subdomains). For example, consider foo.example.com and their subdomains). For example, consider foo.example.com and
bar.example.com. The foo.example.com server can set a cookie with a bar.example.com. The foo.example.com server can set a cookie with a
Domain attribute of ".example.com", and the user agent will include Domain attribute of ".example.com", and the user agent will include
that cookie in HTTP requests to bar.example.com. In the worst case, that cookie in HTTP requests to bar.example.com. In the worst case,
bar.example.com will be unable to distinguish this cookie from a bar.example.com will be unable to distinguish this cookie from a
cookie it set itself. The foo.example.com server might be able to cookie it set itself. The foo.example.com server might be able to
leverage this ability to mount an attack against bar.example.com. leverage this ability to mount an attack against bar.example.com.
Similarly, an active network attacker can inject cookies into the Similarly, an active network attacker can inject cookies into the
Cookie header sent to https://example.com/ by impersonating a Cookie header sent to https://example.com/ by impersonating a
response from http://example.com/ and injecting a Set-Cookie header. response from http://example.com/ and injecting a Set-Cookie header.
The HTTPS server at example.com will be unable to distinguish these The HTTPS server at example.com will be unable to distinguish these
cookies from cookies that it set itself in an HTTPS response. An cookies from cookies that it set itself in an HTTPS response. An
active network attacker might be able to leverage this ability to active network attacker might be able to leverage this ability to
mount an attack against example.com even if example.com uses HTTPS mount an attack against example.com even if example.com uses HTTPS
exclusively. exclusively.
Servers can partially mitigate these attacks by encrypting and Servers can partially mitigate these attacks by encrypting and
signing their cookies. However, using cryptography does not fully signing their cookies. However, using cryptography does not mitigate
ameliorate the issue because an attacker can replay a cookie he or the issue completely because an attacker can replay a cookie he or
she received from the authentic example.com server in the user's she received from the authentic example.com server in the user's
session, with unpredictable results. session, with unpredictable results.
8. Normative References 8. Normative References
[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.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
 End of changes. 34 change blocks. 
112 lines changed or deleted 135 lines changed or added

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