doc: Add RFC documents

1 files changed, 2075 insertions, 0 deletions

diff --git a/doc/rfc/rfc6265.txt b/doc/rfc/rfc6265.txt
new file mode 100644
index 0000000..48d5cd8
--- /dev/null
+++ b/doc/rfc/rfc6265.txt
@@ -0,0 +1,2075 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          A. Barth
+Request for Comments: 6265                                 U.C. Berkeley
+Obsoletes: 2965                                               April 2011
+Category: Standards Track
+ISSN: 2070-1721
+
+
+                    HTTP State Management Mechanism
+
+Abstract
+
+   This document defines the HTTP Cookie and Set-Cookie header fields.
+   These header fields can be used by HTTP servers to store state
+   (called cookies) at HTTP user agents, letting the servers maintain a
+   stateful session over the mostly stateless HTTP protocol.  Although
+   cookies have many historical infelicities that degrade their security
+   and privacy, the Cookie and Set-Cookie header fields are widely used
+   on the Internet.  This document obsoletes RFC 2965.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6265.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Barth                        Standards Track                    [Page 1]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   This document may contain material 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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Conventions .....................................................4
+      2.1. Conformance Criteria .......................................4
+      2.2. Syntax Notation ............................................5
+      2.3. Terminology ................................................5
+   3. Overview ........................................................6
+      3.1. Examples ...................................................6
+   4. Server Requirements .............................................8
+      4.1. Set-Cookie .................................................8
+           4.1.1. Syntax ..............................................8
+           4.1.2. Semantics (Non-Normative) ..........................10
+      4.2. Cookie ....................................................13
+           4.2.1. Syntax .............................................13
+           4.2.2. Semantics ..........................................13
+   5. User Agent Requirements ........................................14
+      5.1. Subcomponent Algorithms ...................................14
+           5.1.1. Dates ..............................................14
+           5.1.2. Canonicalized Host Names ...........................16
+           5.1.3. Domain Matching ....................................16
+           5.1.4. Paths and Path-Match ...............................16
+      5.2. The Set-Cookie Header .....................................17
+           5.2.1. The Expires Attribute ..............................19
+           5.2.2. The Max-Age Attribute ..............................20
+           5.2.3. The Domain Attribute ...............................20
+           5.2.4. The Path Attribute .................................21
+           5.2.5. The Secure Attribute ...............................21
+           5.2.6. The HttpOnly Attribute .............................21
+      5.3. Storage Model .............................................21
+      5.4. The Cookie Header .........................................25
+   6. Implementation Considerations ..................................27
+      6.1. Limits ....................................................27
+      6.2. Application Programming Interfaces ........................27
+      6.3. IDNA Dependency and Migration .............................27
+   7. Privacy Considerations .........................................28
+
+
+
+Barth                        Standards Track                    [Page 2]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+      7.1. Third-Party Cookies .......................................28
+      7.2. User Controls .............................................28
+      7.3. Expiration Dates ..........................................29
+   8. Security Considerations ........................................29
+      8.1. Overview ..................................................29
+      8.2. Ambient Authority .........................................30
+      8.3. Clear Text ................................................30
+      8.4. Session Identifiers .......................................31
+      8.5. Weak Confidentiality ......................................32
+      8.6. Weak Integrity ............................................32
+      8.7. Reliance on DNS ...........................................33
+   9. IANA Considerations ............................................33
+      9.1. Cookie ....................................................34
+      9.2. Set-Cookie ................................................34
+      9.3. Cookie2 ...................................................34
+      9.4. Set-Cookie2 ...............................................34
+   10. References ....................................................35
+      10.1. Normative References .....................................35
+      10.2. Informative References ...................................35
+   Appendix A. Acknowledgements ......................................37
+
+1.  Introduction
+
+   This document defines the HTTP Cookie and Set-Cookie header fields.
+   Using the Set-Cookie header field, an HTTP server can pass name/value
+   pairs and associated metadata (called cookies) to a user agent.  When
+   the user agent makes subsequent requests to the server, the user
+   agent uses the metadata and other information to determine whether to
+   return the name/value pairs in the Cookie header.
+
+   Although simple on their surface, cookies have a number of
+   complexities.  For example, the server indicates a scope for each
+   cookie when sending it to the user agent.  The scope indicates the
+   maximum amount of time in which the user agent should return the
+   cookie, the servers to which the user agent should return the cookie,
+   and the URI schemes for which the cookie is applicable.
+
+   For historical reasons, cookies contain a number of security and
+   privacy infelicities.  For example, a server can indicate that a
+   given cookie is intended for "secure" connections, but the Secure
+   attribute does not provide integrity in the presence of an active
+   network attacker.  Similarly, cookies for a given host are shared
+   across all the ports on that host, even though the usual "same-origin
+   policy" used by web browsers isolates content retrieved via different
+   ports.
+
+   There are two audiences for this specification: developers of cookie-
+   generating servers and developers of cookie-consuming user agents.
+
+
+
+Barth                        Standards Track                    [Page 3]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   To maximize interoperability with user agents, servers SHOULD limit
+   themselves to the well-behaved profile defined in Section 4 when
+   generating cookies.
+
+   User agents MUST implement the more liberal processing rules defined
+   in Section 5, in order to maximize interoperability with existing
+   servers that do not conform to the well-behaved profile defined in
+   Section 4.
+
+   This document specifies the syntax and semantics of these headers as
+   they are actually used on the Internet.  In particular, this document
+   does not create new syntax or semantics beyond those in use today.
+   The recommendations for cookie generation provided in Section 4
+   represent a preferred subset of current server behavior, and even the
+   more liberal cookie processing algorithm provided in Section 5 does
+   not recommend all of the syntactic and semantic variations in use
+   today.  Where some existing software differs from the recommended
+   protocol in significant ways, the document contains a note explaining
+   the difference.
+
+   Prior to this document, there were at least three descriptions of
+   cookies: the so-called "Netscape cookie specification" [Netscape],
+   RFC 2109 [RFC2109], and RFC 2965 [RFC2965].  However, none of these
+   documents describe how the Cookie and Set-Cookie headers are actually
+   used on the Internet (see [Kri2001] for historical context).  In
+   relation to previous IETF specifications of HTTP state management
+   mechanisms, this document requests the following actions:
+
+   1.  Change the status of [RFC2109] to Historic (it has already been
+       obsoleted by [RFC2965]).
+
+   2.  Change the status of [RFC2965] to Historic.
+
+   3.  Indicate that [RFC2965] has been obsoleted by this document.
+
+   In particular, in moving RFC 2965 to Historic and obsoleting it, this
+   document deprecates the use of the Cookie2 and Set-Cookie2 header
+   fields.
+
+2.  Conventions
+
+2.1.  Conformance Criteria
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+Barth                        Standards Track                    [Page 4]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   Requirements phrased in the imperative as part of algorithms (such as
+   "strip any leading space characters" or "return false and abort these
+   steps") are to be interpreted with the meaning of the key word
+   ("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm.
+
+   Conformance requirements phrased as algorithms or specific steps can
+   be implemented in any manner, so long as the end result is
+   equivalent.  In particular, the algorithms defined in this
+   specification are intended to be easy to understand and are not
+   intended to be performant.
+
+2.2.  Syntax Notation
+
+   This specification uses the Augmented Backus-Naur Form (ABNF)
+   notation of [RFC5234].
+
+   The following core rules are included by reference, as defined in
+   [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
+   (CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
+   HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet),
+   OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB
+   (horizontal tab), CHAR (any [USASCII] character), VCHAR (any visible
+   [USASCII] character), and WSP (whitespace).
+
+   The OWS (optional whitespace) rule is used where zero or more linear
+   whitespace characters MAY appear:
+
+   OWS            = *( [ obs-fold ] WSP )
+                    ; "optional" whitespace
+   obs-fold       = CRLF
+
+   OWS SHOULD either not be produced or be produced as a single SP
+   character.
+
+2.3.  Terminology
+
+   The terms user agent, client, server, proxy, and origin server have
+   the same meaning as in the HTTP/1.1 specification ([RFC2616], Section
+   1.3).
+
+   The request-host is the name of the host, as known by the user agent,
+   to which the user agent is sending an HTTP request or from which it
+   is receiving an HTTP response (i.e., the name of the host to which it
+   sent the corresponding HTTP request).
+
+   The term request-uri is defined in Section 5.1.2 of [RFC2616].
+
+
+
+
+
+Barth                        Standards Track                    [Page 5]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   Two sequences of octets are said to case-insensitively match each
+   other if and only if they are equivalent under the i;ascii-casemap
+   collation defined in [RFC4790].
+
+   The term string means a sequence of non-NUL octets.
+
+3.  Overview
+
+   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
+   state information to the origin server.
+
+   To store state, the origin server includes a Set-Cookie header in an
+   HTTP response.  In subsequent requests, the user agent returns a
+   Cookie request header to the origin server.  The Cookie header
+   contains cookies the user agent received in previous Set-Cookie
+   headers.  The origin server is free to ignore the Cookie header or
+   use its contents for an application-defined purpose.
+
+   Origin servers MAY send a Set-Cookie response header with any
+   response.  User agents MAY ignore Set-Cookie headers contained in
+   responses with 100-level status codes but MUST process Set-Cookie
+   headers contained in other responses (including responses with 400-
+   and 500-level status codes).  An origin server can include multiple
+   Set-Cookie header fields in a single response.  The presence of a
+   Cookie or a Set-Cookie header field does not preclude HTTP caches
+   from storing and reusing a response.
+
+   Origin servers SHOULD NOT fold multiple Set-Cookie header fields into
+   a single header field.  The usual mechanism for folding HTTP headers
+   fields (i.e., as defined in [RFC2616]) might change the semantics of
+   the Set-Cookie header field because the %x2C (",") character is used
+   by Set-Cookie in a way that conflicts with such folding.
+
+3.1.  Examples
+
+   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
+   HTTP requests that are within the scope of the cookie.  For example,
+   the server can send the user agent a "session identifier" named SID
+   with the value 31d4d96e407aad42.  The user agent then returns the
+   session identifier in subsequent requests.
+
+
+
+
+
+
+
+
+
+Barth                        Standards Track                    [Page 6]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   == Server -> User Agent ==
+
+   Set-Cookie: SID=31d4d96e407aad42
+
+   == User Agent -> Server ==
+
+   Cookie: SID=31d4d96e407aad42
+
+   The server can alter the default scope of the cookie using the Path
+   and Domain attributes.  For example, the server can instruct the user
+   agent to return the cookie to every path and every subdomain of
+   example.com.
+
+   == Server -> User Agent ==
+
+   Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com
+
+   == User Agent -> Server ==
+
+   Cookie: SID=31d4d96e407aad42
+
+   As shown in the next example, the server can store multiple cookies
+   at the user agent.  For example, the server can store a session
+   identifier as well as the user's preferred language by returning two
+   Set-Cookie header fields.  Notice that the server uses the Secure and
+   HttpOnly attributes to provide additional security protections for
+   the more sensitive session identifier (see Section 4.1.2.)
+
+   == Server -> User Agent ==
+
+   Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
+   Set-Cookie: lang=en-US; Path=/; Domain=example.com
+
+   == User Agent -> Server ==
+
+   Cookie: SID=31d4d96e407aad42; lang=en-US
+
+   Notice that the Cookie header above contains two cookies, one named
+   SID and one named lang.  If the server wishes the user agent to
+   persist the cookie over multiple "sessions" (e.g., user agent
+   restarts), the server can specify an expiration date in the Expires
+   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.
+
+
+
+
+
+
+
+Barth                        Standards Track                    [Page 7]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   == Server -> User Agent ==
+
+   Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT
+
+   == User Agent -> Server ==
+
+   Cookie: SID=31d4d96e407aad42; lang=en-US
+
+   Finally, to remove a cookie, the server returns a Set-Cookie header
+   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
+   the Set-Cookie header match the values used when the cookie was
+   created.
+
+   == Server -> User Agent ==
+
+   Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT
+
+   == User Agent -> Server ==
+
+   Cookie: SID=31d4d96e407aad42
+
+4.  Server Requirements
+
+   This section describes the syntax and semantics of a well-behaved
+   profile of the Cookie and Set-Cookie headers.
+
+4.1.  Set-Cookie
+
+   The Set-Cookie HTTP response header is used to send cookies from the
+   server to the user agent.
+
+4.1.1.  Syntax
+
+   Informally, the Set-Cookie response header contains the header name
+   "Set-Cookie" followed by a ":" and a cookie.  Each cookie begins with
+   a name-value-pair, followed by zero or more attribute-value pairs.
+   Servers SHOULD NOT send Set-Cookie headers that fail to conform to
+   the following grammar:
+
+
+
+
+
+
+
+
+
+
+
+
+Barth                        Standards Track                    [Page 8]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+ set-cookie-header = "Set-Cookie:" SP set-cookie-string
+ set-cookie-string = cookie-pair *( ";" SP cookie-av )
+ cookie-pair       = cookie-name "=" cookie-value
+ cookie-name       = token
+ cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
+ cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
+                       ; US-ASCII characters excluding CTLs,
+                       ; whitespace DQUOTE, comma, semicolon,
+                       ; and backslash
+ token             = <token, defined in [RFC2616], Section 2.2>
+
+ cookie-av         = expires-av / max-age-av / domain-av /
+                     path-av / secure-av / httponly-av /
+                     extension-av
+ expires-av        = "Expires=" sane-cookie-date
+ sane-cookie-date  = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
+ max-age-av        = "Max-Age=" non-zero-digit *DIGIT
+                       ; In practice, both expires-av and max-age-av
+                       ; are limited to dates representable by the
+                       ; user agent.
+ non-zero-digit    = %x31-39
+                       ; digits 1 through 9
+ domain-av         = "Domain=" domain-value
+ domain-value      = <subdomain>
+                       ; defined in [RFC1034], Section 3.5, as
+                       ; enhanced by [RFC1123], Section 2.1
+ path-av           = "Path=" path-value
+ path-value        = <any CHAR except CTLs or ";">
+ secure-av         = "Secure"
+ httponly-av       = "HttpOnly"
+ extension-av      = <any CHAR except CTLs or ";">
+
+   Note that some of the grammatical terms above reference documents
+   that use different grammatical notations than this document (which
+   uses ABNF from [RFC5234]).
+
+   The semantics of the cookie-value are not defined by this document.
+
+   To maximize compatibility with user agents, servers that wish to
+   store arbitrary data in a cookie-value SHOULD encode that data, for
+   example, using Base64 [RFC4648].
+
+   The portions of the set-cookie-string produced by the cookie-av term
+   are known as attributes.  To maximize compatibility with user agents,
+   servers SHOULD NOT produce two attributes with the same name in the
+   same set-cookie-string.  (See Section 5.3 for how user agents handle
+   this case.)
+
+
+
+
+Barth                        Standards Track                    [Page 9]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   Servers SHOULD NOT include more than one Set-Cookie header field in
+   the same response with the same cookie-name.  (See Section 5.2 for
+   how user agents handle this case.)
+
+   If a server sends multiple responses containing Set-Cookie headers
+   concurrently to the user agent (e.g., when communicating with the
+   user agent over multiple sockets), these responses create a "race
+   condition" that can lead to unpredictable behavior.
+
+   NOTE: Some existing user agents differ in their interpretation of
+   two-digit years.  To avoid compatibility issues, servers SHOULD use
+   the rfc1123-date format, which requires a four-digit year.
+
+   NOTE: Some user agents store and process dates in cookies as 32-bit
+   UNIX time_t values.  Implementation bugs in the libraries supporting
+   time_t processing on some systems might cause such user agents to
+   process dates after the year 2038 incorrectly.
+
+4.1.2.  Semantics (Non-Normative)
+
+   This section describes simplified semantics of the Set-Cookie header.
+   These semantics are detailed enough to be useful for understanding
+   the most common uses of cookies by servers.  The full semantics are
+   described in Section 5.
+
+   When the user agent receives a Set-Cookie header, the user agent
+   stores the cookie together with its attributes.  Subsequently, when
+   the user agent makes an HTTP request, the user agent includes the
+   applicable, non-expired cookies in the Cookie header.
+
+   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,
+   the existing cookie is evicted and replaced with the new cookie.
+   Notice that servers can delete cookies by sending the user agent a
+   new cookie with an Expires attribute with a value in the past.
+
+   Unless the cookie's attributes indicate otherwise, the cookie is
+   returned only to the origin server (and not, for example, to any
+   subdomains), and it expires at the end of the current session (as
+   defined by the user agent).  User agents ignore unrecognized cookie
+   attributes (but not the entire cookie).
+
+
+
+
+
+
+
+
+
+
+Barth                        Standards Track                   [Page 10]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+4.1.2.1.  The Expires Attribute
+
+   The Expires attribute indicates the maximum lifetime of the cookie,
+   represented as the date and time at which the cookie expires.  The
+   user agent is not required to retain the cookie until the specified
+   date has passed.  In fact, user agents often evict cookies due to
+   memory pressure or privacy concerns.
+
+4.1.2.2.  The Max-Age Attribute
+
+   The Max-Age attribute indicates the maximum lifetime of the cookie,
+   represented as the number of seconds until the cookie expires.  The
+   user agent is not required to retain the cookie for the specified
+   duration.  In fact, user agents often evict cookies due to memory
+   pressure or privacy concerns.
+
+      NOTE: Some existing user agents do not support the Max-Age
+      attribute.  User agents that do not support the Max-Age attribute
+      ignore the attribute.
+
+   If a cookie has both the Max-Age and the Expires attribute, the Max-
+   Age attribute has precedence and controls the expiration date of the
+   cookie.  If a cookie has neither the Max-Age nor the Expires
+   attribute, the user agent will retain the cookie until "the current
+   session is over" (as defined by the user agent).
+
+4.1.2.3.  The Domain Attribute
+
+   The Domain attribute specifies those hosts to which the cookie will
+   be sent.  For example, if the value of the Domain attribute is
+   "example.com", the user agent will include the cookie in the Cookie
+   header when making HTTP requests to example.com, www.example.com, and
+   www.corp.example.com.  (Note that a leading %x2E ("."), if present,
+   is ignored even though that character is not permitted, but a
+   trailing %x2E ("."), if present, will cause the user agent to ignore
+   the attribute.)  If the server omits the Domain attribute, the user
+   agent will return the cookie only to the origin server.
+
+      WARNING: Some existing user agents treat an absent Domain
+      attribute as if the Domain attribute were present and contained
+      the current host name.  For example, if example.com returns a Set-
+      Cookie header without a Domain attribute, these user agents will
+      erroneously send the cookie to www.example.com as well.
+
+
+
+
+
+
+
+
+Barth                        Standards Track                   [Page 11]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   The user agent will reject cookies unless the Domain attribute
+   specifies a scope for the cookie that would include the origin
+   server.  For example, the user agent will accept a cookie with a
+   Domain attribute of "example.com" or of "foo.example.com" from
+   foo.example.com, but the user agent will not accept a cookie with a
+   Domain attribute of "bar.example.com" or of "baz.foo.example.com".
+
+   NOTE: For security reasons, many user agents are configured to reject
+   Domain attributes that correspond to "public suffixes".  For example,
+   some user agents will reject Domain attributes of "com" or "co.uk".
+   (See Section 5.3 for more information.)
+
+4.1.2.4.  The Path Attribute
+
+   The scope of each cookie is limited to a set of paths, controlled by
+   the Path attribute.  If the server omits the Path attribute, the user
+   agent will use the "directory" of the request-uri's path component as
+   the default value.  (See Section 5.1.4 for more details.)
+
+   The user agent will include the cookie in an HTTP request only if the
+   path portion of the request-uri matches (or is a subdirectory of) the
+   cookie's Path attribute, where the %x2F ("/") character is
+   interpreted as a directory separator.
+
+   Although seemingly useful for isolating cookies between different
+   paths within a given host, the Path attribute cannot be relied upon
+   for security (see Section 8).
+
+4.1.2.5.  The Secure Attribute
+
+   The Secure attribute limits the scope of the cookie to "secure"
+   channels (where "secure" is defined by the user agent).  When a
+   cookie has the Secure attribute, the user agent will include the
+   cookie in an HTTP request only if the request is transmitted over a
+   secure channel (typically HTTP over Transport Layer Security (TLS)
+   [RFC2818]).
+
+   Although seemingly useful for protecting cookies from active network
+   attackers, the Secure attribute protects only the cookie's
+   confidentiality.  An active network attacker can overwrite Secure
+   cookies from an insecure channel, disrupting their integrity (see
+   Section 8.6 for more details).
+
+
+
+
+
+
+
+
+
+Barth                        Standards Track                   [Page 12]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+4.1.2.6.  The HttpOnly Attribute
+
+   The HttpOnly attribute limits the scope of the cookie to HTTP
+   requests.  In particular, the attribute instructs the user agent to
+   omit the cookie when providing access to cookies via "non-HTTP" APIs
+   (such as a web browser API that exposes cookies to scripts).
+
+   Note that the HttpOnly attribute is independent of the Secure
+   attribute: a cookie can have both the HttpOnly and the Secure
+   attribute.
+
+4.2.  Cookie
+
+4.2.1.  Syntax
+
+   The user agent sends stored cookies to the origin server in the
+   Cookie header.  If the server conforms to the requirements in
+   Section 4.1 (and the user agent conforms to the requirements in
+   Section 5), the user agent will send a Cookie header that conforms to
+   the following grammar:
+
+   cookie-header = "Cookie:" OWS cookie-string OWS
+   cookie-string = cookie-pair *( ";" SP cookie-pair )
+
+4.2.2.  Semantics
+
+   Each cookie-pair represents a cookie stored by the user agent.  The
+   cookie-pair contains the cookie-name and cookie-value the user agent
+   received in the Set-Cookie header.
+
+   Notice that the cookie attributes are not returned.  In particular,
+   the server cannot determine from the Cookie header alone when a
+   cookie will expire, for which hosts the cookie is valid, for which
+   paths the cookie is valid, or whether the cookie was set with the
+   Secure or HttpOnly attributes.
+
+   The semantics of individual cookies in the Cookie header are not
+   defined by this document.  Servers are expected to imbue these
+   cookies with application-specific semantics.
+
+   Although cookies are serialized linearly in the Cookie header,
+   servers SHOULD NOT rely upon the serialization order.  In particular,
+   if the Cookie header contains two cookies with the same name (e.g.,
+   that were set with different Path or Domain attributes), servers
+   SHOULD NOT rely upon the order in which these cookies appear in the
+   header.
+
+
+
+
+
+Barth                        Standards Track                   [Page 13]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+5.  User Agent Requirements
+
+   This section specifies the Cookie and Set-Cookie headers in
+   sufficient detail that a user agent implementing these requirements
+   precisely can interoperate with existing servers (even those that do
+   not conform to the well-behaved profile described in Section 4).
+
+   A user agent could enforce more restrictions than those specified
+   herein (e.g., for the sake of improved security); however,
+   experiments have shown that such strictness reduces the likelihood
+   that a user agent will be able to interoperate with existing servers.
+
+5.1.  Subcomponent Algorithms
+
+   This section defines some algorithms used by user agents to process
+   specific subcomponents of the Cookie and Set-Cookie headers.
+
+5.1.1.  Dates
+
+   The user agent MUST use an algorithm equivalent to the following
+   algorithm to parse a cookie-date.  Note that the various boolean
+   flags defined as a part of the algorithm (i.e., found-time, found-
+   day-of-month, found-month, found-year) are initially "not set".
+
+   1.  Using the grammar below, divide the cookie-date into date-tokens.
+
+   cookie-date     = *delimiter date-token-list *delimiter
+   date-token-list = date-token *( 1*delimiter date-token )
+   date-token      = 1*non-delimiter
+
+   delimiter       = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
+   non-delimiter   = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
+   non-digit       = %x00-2F / %x3A-FF
+
+   day-of-month    = 1*2DIGIT ( non-digit *OCTET )
+   month           = ( "jan" / "feb" / "mar" / "apr" /
+                       "may" / "jun" / "jul" / "aug" /
+                       "sep" / "oct" / "nov" / "dec" ) *OCTET
+   year            = 2*4DIGIT ( non-digit *OCTET )
+   time            = hms-time ( non-digit *OCTET )
+   hms-time        = time-field ":" time-field ":" time-field
+   time-field      = 1*2DIGIT
+
+   2.  Process each date-token sequentially in the order the date-tokens
+       appear in the cookie-date:
+
+
+
+
+
+
+Barth                        Standards Track                   [Page 14]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+       1.  If the found-time flag is not set and the token matches the
+           time production, set the found-time flag and set the hour-
+           value, minute-value, and second-value to the numbers denoted
+           by the digits in the date-token, respectively.  Skip the
+           remaining sub-steps and continue to the next date-token.
+
+       2.  If the found-day-of-month flag is not set and the date-token
+           matches the day-of-month production, set the found-day-of-
+           month flag and set the day-of-month-value to the number
+           denoted by the date-token.  Skip the remaining sub-steps and
+           continue to the next date-token.
+
+       3.  If the found-month flag is not set and the date-token matches
+           the month production, set the found-month flag and set the
+           month-value to the month denoted by the date-token.  Skip the
+           remaining sub-steps and continue to the next date-token.
+
+       4.  If the found-year flag is not set and the date-token matches
+           the year production, set the found-year flag and set the
+           year-value to the number denoted by the date-token.  Skip the
+           remaining sub-steps and continue to the next date-token.
+
+   3.  If the year-value is greater than or equal to 70 and less than or
+       equal to 99, increment the year-value by 1900.
+
+   4.  If the year-value is greater than or equal to 0 and less than or
+       equal to 69, increment the year-value by 2000.
+
+       1.  NOTE: Some existing user agents interpret two-digit years
+           differently.
+
+   5.  Abort these steps and fail to parse the cookie-date if:
+
+       *  at least one of the found-day-of-month, found-month, found-
+          year, or found-time flags is not set,
+
+       *  the day-of-month-value is less than 1 or greater than 31,
+
+       *  the year-value is less than 1601,
+
+       *  the hour-value is greater than 23,
+
+       *  the minute-value is greater than 59, or
+
+       *  the second-value is greater than 59.
+
+       (Note that leap seconds cannot be represented in this syntax.)
+
+
+
+
+Barth                        Standards Track                   [Page 15]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   6.  Let the parsed-cookie-date be the date whose day-of-month, month,
+       year, hour, minute, and second (in UTC) are the day-of-month-
+       value, the month-value, the year-value, the hour-value, the
+       minute-value, and the second-value, respectively.  If no such
+       date exists, abort these steps and fail to parse the cookie-date.
+
+   7.  Return the parsed-cookie-date as the result of this algorithm.
+
+5.1.2.  Canonicalized Host Names
+
+   A canonicalized host name is the string generated by the following
+   algorithm:
+
+   1.  Convert the host name to a sequence of individual domain name
+       labels.
+
+   2.  Convert each label that is not a Non-Reserved LDH (NR-LDH) label,
+       to an A-label (see Section 2.3.2.1 of [RFC5890] for the former
+       and latter), or to a "punycode label" (a label resulting from the
+       "ToASCII" conversion in Section 4 of [RFC3490]), as appropriate
+       (see Section 6.3 of this specification).
+
+   3.  Concatenate the resulting labels, separated by a %x2E (".")
+       character.
+
+5.1.3.  Domain Matching
+
+   A string domain-matches a given domain string if at least one of the
+   following conditions hold:
+
+   o  The domain string and the string are identical.  (Note that both
+      the domain string and the string will have been canonicalized to
+      lower case at this point.)
+
+   o  All of the following conditions hold:
+
+      *  The domain string is a suffix of the string.
+
+      *  The last character of the string that is not included in the
+         domain string is a %x2E (".") character.
+
+      *  The string is a host name (i.e., not an IP address).
+
+5.1.4.  Paths and Path-Match
+
+   The user agent MUST use an algorithm equivalent to the following
+   algorithm to compute the default-path of a cookie:
+
+
+
+
+Barth                        Standards Track                   [Page 16]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   1.  Let uri-path be the path portion of the request-uri if such a
+       portion exists (and empty otherwise).  For example, if the
+       request-uri contains just a path (and optional query string),
+       then the uri-path is that path (without the %x3F ("?") character
+       or query string), and if the request-uri contains a full
+       absoluteURI, the uri-path is the path component of that URI.
+
+   2.  If the uri-path is empty or if the first character of the uri-
+       path is not a %x2F ("/") character, output %x2F ("/") and skip
+       the remaining steps.
+
+   3.  If the uri-path contains no more than one %x2F ("/") character,
+       output %x2F ("/") and skip the remaining step.
+
+   4.  Output the characters of the uri-path from the first character up
+       to, but not including, the right-most %x2F ("/").
+
+   A request-path path-matches a given cookie-path if at least one of
+   the following conditions holds:
+
+   o  The cookie-path and the request-path are identical.
+
+   o  The cookie-path is a prefix of the request-path, and the last
+      character of the cookie-path is %x2F ("/").
+
+   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-
+      path is a %x2F ("/") character.
+
+5.2.  The Set-Cookie Header
+
+   When a user agent receives a Set-Cookie header field in an HTTP
+   response, the user agent MAY ignore the Set-Cookie header field in
+   its entirety.  For example, the user agent might wish to block
+   responses to "third-party" requests from setting cookies (see
+   Section 7.1).
+
+   If the user agent does not ignore the Set-Cookie header field in its
+   entirety, the user agent MUST parse the field-value of the Set-Cookie
+   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.
+
+
+
+Barth                        Standards Track                   [Page 17]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   A user agent MUST use an algorithm equivalent to the following
+   algorithm to parse a "set-cookie-string":
+
+   1.  If the set-cookie-string contains a %x3B (";") character:
+
+          The name-value-pair string consists of the characters up to,
+          but not including, the first %x3B (";"), and the unparsed-
+          attributes consist of the remainder of the set-cookie-string
+          (including the %x3B (";") in question).
+
+       Otherwise:
+
+          The name-value-pair string consists of all the characters
+          contained in the set-cookie-string, and the unparsed-
+          attributes is the empty string.
+
+   2.  If the name-value-pair string lacks a %x3D ("=") character,
+       ignore the set-cookie-string entirely.
+
+   3.  The (possibly empty) name string consists of the characters up
+       to, but not including, the first %x3D ("=") character, and the
+       (possibly empty) value string consists of the characters after
+       the first %x3D ("=") character.
+
+   4.  Remove any leading or trailing WSP characters from the name
+       string and the value string.
+
+   5.  If the name string is empty, ignore the set-cookie-string
+       entirely.
+
+   6.  The cookie-name is the name string, and the cookie-value is the
+       value string.
+
+   The user agent MUST use an algorithm equivalent to the following
+   algorithm to parse the unparsed-attributes:
+
+   1.  If the unparsed-attributes string is empty, skip the rest of
+       these steps.
+
+   2.  Discard the first character of the unparsed-attributes (which
+       will be a %x3B (";") character).
+
+   3.  If the remaining unparsed-attributes contains a %x3B (";")
+       character:
+
+          Consume the characters of the unparsed-attributes up to, but
+          not including, the first %x3B (";") character.
+
+
+
+
+Barth                        Standards Track                   [Page 18]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+       Otherwise:
+
+          Consume the remainder of the unparsed-attributes.
+
+       Let the cookie-av string be the characters consumed in this step.
+
+   4.  If the cookie-av string contains a %x3D ("=") character:
+
+          The (possibly empty) attribute-name string consists of the
+          characters up to, but not including, the first %x3D ("=")
+          character, and the (possibly empty) attribute-value string
+          consists of the characters after the first %x3D ("=")
+          character.
+
+       Otherwise:
+
+          The attribute-name string consists of the entire cookie-av
+          string, and the attribute-value string is empty.
+
+   5.  Remove any leading or trailing WSP characters from the attribute-
+       name string and the attribute-value string.
+
+   6.  Process the attribute-name and attribute-value according to the
+       requirements in the following subsections.  (Notice that
+       attributes with unrecognized attribute-names are ignored.)
+
+   7.  Return to Step 1 of this algorithm.
+
+   When the user agent finishes parsing the set-cookie-string, the user
+   agent is said to "receive a cookie" from the request-uri with name
+   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
+
+   If the attribute-name case-insensitively matches the string
+   "Expires", the user agent MUST process the cookie-av as follows.
+
+   Let the expiry-time be the result of parsing the attribute-value as
+   cookie-date (see Section 5.1.1).
+
+   If the attribute-value failed to parse as a cookie date, ignore the
+   cookie-av.
+
+   If the expiry-time is later than the last date the user agent can
+   represent, the user agent MAY replace the expiry-time with the last
+   representable date.
+
+
+
+Barth                        Standards Track                   [Page 19]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   If the expiry-time is earlier than the earliest date the user agent
+   can represent, the user agent MAY replace the expiry-time with the
+   earliest representable date.
+
+   Append an attribute to the cookie-attribute-list with an attribute-
+   name of Expires and an attribute-value of expiry-time.
+
+5.2.2.  The Max-Age Attribute
+
+   If the attribute-name case-insensitively matches the string "Max-
+   Age", the user agent MUST process the cookie-av as follows.
+
+   If the first character of the attribute-value is not a DIGIT or a "-"
+   character, ignore the cookie-av.
+
+   If the remainder of attribute-value contains a non-DIGIT character,
+   ignore the cookie-av.
+
+   Let delta-seconds be the attribute-value converted to an integer.
+
+   If delta-seconds is less than or equal to zero (0), let expiry-time
+   be the earliest representable date and time.  Otherwise, let the
+   expiry-time be the current date and time plus delta-seconds seconds.
+
+   Append an attribute to the cookie-attribute-list with an attribute-
+   name of Max-Age and an attribute-value of expiry-time.
+
+5.2.3.  The Domain Attribute
+
+   If the attribute-name case-insensitively matches the string "Domain",
+   the user agent MUST process the cookie-av as follows.
+
+   If the attribute-value is empty, the behavior is undefined.  However,
+   the user agent SHOULD ignore the cookie-av entirely.
+
+   If the first character of the attribute-value string is %x2E ("."):
+
+      Let cookie-domain be the attribute-value without the leading %x2E
+      (".") character.
+
+   Otherwise:
+
+      Let cookie-domain be the entire attribute-value.
+
+   Convert the cookie-domain to lower case.
+
+   Append an attribute to the cookie-attribute-list with an attribute-
+   name of Domain and an attribute-value of cookie-domain.
+
+
+
+Barth                        Standards Track                   [Page 20]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+5.2.4.  The Path Attribute
+
+   If the attribute-name case-insensitively matches the string "Path",
+   the user agent MUST process the cookie-av as follows.
+
+   If the attribute-value is empty or if the first character of the
+   attribute-value is not %x2F ("/"):
+
+      Let cookie-path be the default-path.
+
+   Otherwise:
+
+      Let cookie-path be the attribute-value.
+
+   Append an attribute to the cookie-attribute-list with an attribute-
+   name of Path and an attribute-value of cookie-path.
+
+5.2.5.  The Secure Attribute
+
+   If the attribute-name case-insensitively matches the string "Secure",
+   the user agent MUST append an attribute to the cookie-attribute-list
+   with an attribute-name of Secure and an empty attribute-value.
+
+5.2.6.  The HttpOnly Attribute
+
+   If the attribute-name case-insensitively matches the string
+   "HttpOnly", the user agent MUST append an attribute to the cookie-
+   attribute-list with an attribute-name of HttpOnly and an empty
+   attribute-value.
+
+5.3.  Storage Model
+
+   The user agent stores the following fields about each cookie: name,
+   value, expiry-time, domain, path, creation-time, last-access-time,
+   persistent-flag, host-only-flag, secure-only-flag, and http-only-
+   flag.
+
+   When the user agent "receives a cookie" from a request-uri with name
+   cookie-name, value cookie-value, and attributes cookie-attribute-
+   list, the user agent MUST process the cookie as follows:
+
+   1.   A user agent MAY ignore a received cookie in its entirety.  For
+        example, the user agent might wish to block receiving cookies
+        from "third-party" responses or the user agent might not wish to
+        store cookies that exceed some size.
+
+
+
+
+
+
+Barth                        Standards Track                   [Page 21]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   2.   Create a new cookie with name cookie-name, value cookie-value.
+        Set the creation-time and the last-access-time to the current
+        date and time.
+
+   3.   If the cookie-attribute-list contains an attribute with an
+        attribute-name of "Max-Age":
+
+           Set the cookie's persistent-flag to true.
+
+           Set the cookie's expiry-time to attribute-value of the last
+           attribute in the cookie-attribute-list with an attribute-name
+           of "Max-Age".
+
+        Otherwise, if the cookie-attribute-list contains an attribute
+        with an attribute-name of "Expires" (and does not contain an
+        attribute with an attribute-name of "Max-Age"):
+
+           Set the cookie's persistent-flag to true.
+
+           Set the cookie's expiry-time to attribute-value of the last
+           attribute in the cookie-attribute-list with an attribute-name
+           of "Expires".
+
+        Otherwise:
+
+           Set the cookie's persistent-flag to false.
+
+           Set the cookie's expiry-time to the latest representable
+           date.
+
+   4.   If the cookie-attribute-list contains an attribute with an
+        attribute-name of "Domain":
+
+           Let the domain-attribute be the attribute-value of the last
+           attribute in the cookie-attribute-list with an attribute-name
+           of "Domain".
+
+        Otherwise:
+
+           Let the domain-attribute be the empty string.
+
+   5.   If the user agent is configured to reject "public suffixes" and
+        the domain-attribute is a public suffix:
+
+           If the domain-attribute is identical to the canonicalized
+           request-host:
+
+              Let the domain-attribute be the empty string.
+
+
+
+Barth                        Standards Track                   [Page 22]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+           Otherwise:
+
+              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/>.
+
+   6.   If the domain-attribute is non-empty:
+
+           If the canonicalized request-host does not domain-match the
+           domain-attribute:
+
+              Ignore the cookie entirely and abort these steps.
+
+           Otherwise:
+
+              Set the cookie's host-only-flag to false.
+
+              Set the cookie's domain to the domain-attribute.
+
+        Otherwise:
+
+           Set the cookie's host-only-flag to true.
+
+           Set the cookie's domain to the canonicalized request-host.
+
+   7.   If the cookie-attribute-list contains an attribute with an
+        attribute-name of "Path", set the cookie's path to attribute-
+        value of the last attribute in the cookie-attribute-list with an
+        attribute-name of "Path".  Otherwise, set the cookie's path to
+        the default-path of the request-uri.
+
+   8.   If the cookie-attribute-list contains an attribute with an
+        attribute-name of "Secure", set the cookie's secure-only-flag to
+        true.  Otherwise, set the cookie's secure-only-flag to false.
+
+   9.   If the cookie-attribute-list contains an attribute with an
+        attribute-name of "HttpOnly", set the cookie's http-only-flag to
+        true.  Otherwise, set the cookie's http-only-flag to false.
+
+
+
+
+
+Barth                        Standards Track                   [Page 23]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   10.  If the cookie was received from a "non-HTTP" API and the
+        cookie's http-only-flag is set, abort these steps and ignore the
+        cookie entirely.
+
+   11.  If the cookie store contains a cookie with the same name,
+        domain, and path as the newly created cookie:
+
+        1.  Let old-cookie be the existing cookie with the same name,
+            domain, and path as the newly created cookie.  (Notice that
+            this algorithm maintains the invariant that there is at most
+            one such cookie.)
+
+        2.  If the newly created cookie was received from a "non-HTTP"
+            API and the old-cookie's http-only-flag is set, abort these
+            steps and ignore the newly created cookie entirely.
+
+        3.  Update the creation-time of the newly created cookie to
+            match the creation-time of the old-cookie.
+
+        4.  Remove the old-cookie from 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.
+
+   The user agent MUST evict all expired cookies from 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
+   cookie store if the number of cookies sharing a domain field exceeds
+   some implementation-defined upper bound (such as 50 cookies).
+
+   At any time, the user agent MAY "remove excess cookies" from the
+   cookie store if the cookie store exceeds some predetermined upper
+   bound (such as 3000 cookies).
+
+   When the user agent removes excess cookies from the cookie store, the
+   user agent MUST evict cookies in the following priority order:
+
+   1.  Expired cookies.
+
+   2.  Cookies that share a domain field with more than a predetermined
+       number of other cookies.
+
+   3.  All cookies.
+
+   If two cookies have the same removal priority, the user agent MUST
+   evict the cookie with the earliest last-access date first.
+
+
+
+Barth                        Standards Track                   [Page 24]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   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
+   persistent-flag set to false.
+
+5.4.  The Cookie Header
+
+   The user agent includes stored cookies in the Cookie HTTP request
+   header.
+
+   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
+   example, the user agent might wish to block sending cookies during
+   "third-party" requests from setting cookies (see Section 7.1).
+
+   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
+   algorithm to compute the "cookie-string" from a cookie store and a
+   request-uri:
+
+   1.  Let cookie-list be the set of cookies from the cookie store that
+       meets all of the following requirements:
+
+       *  Either:
+
+             The cookie's host-only-flag is true and the canonicalized
+             request-host is identical to the cookie's domain.
+
+          Or:
+
+             The cookie's host-only-flag is false and the canonicalized
+             request-host domain-matches the cookie's domain.
+
+       *  The request-uri's path path-matches the cookie's path.
+
+       *  If the cookie's secure-only-flag is true, then the request-
+          uri's scheme must denote a "secure" protocol (as defined by
+          the user agent).
+
+             NOTE: The notion of a "secure" protocol is not defined by
+             this document.  Typically, user agents consider a protocol
+             secure if the protocol makes use of transport-layer
+
+
+
+
+
+Barth                        Standards Track                   [Page 25]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+             security, such as SSL or TLS.  For example, most user
+             agents consider "https" to be a scheme that denotes a
+             secure protocol.
+
+       *  If the cookie's http-only-flag is true, then exclude the
+          cookie if the cookie-string is being generated for a "non-
+          HTTP" API (as defined by the user agent).
+
+   2.  The user agent SHOULD sort the cookie-list in the following
+       order:
+
+       *  Cookies with longer paths are listed before cookies with
+          shorter paths.
+
+       *  Among cookies that have equal-length path fields, cookies with
+          earlier creation-times are listed before cookies with later
+          creation-times.
+
+       NOTE: Not all user agents sort the cookie-list in this order, but
+       this order reflects common practice when this document was
+       written, and, historically, there have been servers that
+       (erroneously) depended on this order.
+
+   3.  Update the last-access-time of each cookie in the cookie-list to
+       the current date and time.
+
+   4.  Serialize the cookie-list into a cookie-string by processing each
+       cookie in the cookie-list in order:
+
+       1.  Output the cookie's name, the %x3D ("=") character, and the
+           cookie's value.
+
+       2.  If there is an unprocessed cookie in the cookie-list, output
+           the characters %x3B and %x20 ("; ").
+
+   NOTE: Despite its name, the cookie-string is actually a sequence of
+   octets, not a sequence of characters.  To convert the cookie-string
+   (or components thereof) into a sequence of characters (e.g., for
+   presentation to the user), the user agent might wish to try using the
+   UTF-8 character encoding [RFC3629] to decode the octet sequence.
+   This decoding might fail, however, because not every sequence of
+   octets is valid UTF-8.
+
+
+
+
+
+
+
+
+
+Barth                        Standards Track                   [Page 26]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+6.  Implementation Considerations
+
+6.1.  Limits
+
+   Practical user agent implementations have limits on the number and
+   size of cookies that they can store.  General-use user agents SHOULD
+   provide each of the following minimum capabilities:
+
+   o  At least 4096 bytes per cookie (as measured by the sum of the
+      length of the cookie's name, value, and attributes).
+
+   o  At least 50 cookies per domain.
+
+   o  At least 3000 cookies total.
+
+   Servers SHOULD use as few and as small cookies as possible to avoid
+   reaching these implementation limits and to minimize network
+   bandwidth due to the Cookie header being included in every request.
+
+   Servers SHOULD gracefully degrade if the user agent fails to return
+   one or more cookies in the Cookie header because the user agent might
+   evict any cookie at any time on orders from the user.
+
+6.2.  Application Programming Interfaces
+
+   One reason the Cookie and Set-Cookie headers use such esoteric syntax
+   is that many platforms (both in servers and user agents) provide a
+   string-based application programming interface (API) to cookies,
+   requiring application-layer programmers to generate and parse the
+   syntax used by the Cookie and Set-Cookie headers, which many
+   programmers have done incorrectly, resulting in interoperability
+   problems.
+
+   Instead of providing string-based APIs to cookies, platforms would be
+   well-served by providing more semantic APIs.  It is beyond the scope
+   of this document to recommend specific API designs, but there are
+   clear benefits to accepting an abstract "Date" object instead of a
+   serialized date string.
+
+6.3.  IDNA Dependency and Migration
+
+   IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490].  However, there are
+   differences between the two specifications, and thus there can be
+   differences in processing (e.g., converting) domain name labels that
+   have been registered under one from those registered under the other.
+   There will be a transition period of some time during which IDNA2003-
+   based domain name labels will exist in the wild.  User agents SHOULD
+   implement IDNA2008 [RFC5890] and MAY implement [UTS46] or [RFC5895]
+
+
+
+Barth                        Standards Track                   [Page 27]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   in order to facilitate their IDNA transition.  If a user agent does
+   not implement IDNA2008, the user agent MUST implement IDNA2003
+   [RFC3490].
+
+7.  Privacy Considerations
+
+   Cookies are often criticized for letting servers track users.  For
+   example, a number of "web analytics" companies use cookies to
+   recognize when a user returns to a web site or visits another web
+   site.  Although cookies are not the only mechanism servers can use to
+   track users across HTTP requests, cookies facilitate tracking because
+   they are persistent across user agent sessions and can be shared
+   between hosts.
+
+7.1.  Third-Party Cookies
+
+   Particularly worrisome are so-called "third-party" cookies.  In
+   rendering an HTML document, a user agent often requests resources
+   from other servers (such as advertising networks).  These third-party
+   servers can use cookies to track the user even if the user never
+   visits the server directly.  For example, if a user visits a site
+   that contains content from a third party and then later visits
+   another site that contains content from the same third party, the
+   third party can track the user between the two sites.
+
+   Some user agents restrict how third-party cookies behave.  For
+   example, some of these user agents refuse to send the Cookie header
+   in third-party requests.  Others refuse to process the Set-Cookie
+   header in responses to third-party requests.  User agents vary widely
+   in their third-party cookie policies.  This document grants user
+   agents wide latitude to experiment with third-party cookie policies
+   that balance the privacy and compatibility needs of their users.
+   However, this document does not endorse any particular third-party
+   cookie policy.
+
+   Third-party cookie blocking policies are often ineffective at
+   achieving their privacy goals if servers attempt to work around their
+   restrictions to track users.  In particular, two collaborating
+   servers can often track users without using cookies at all by
+   injecting identifying information into dynamic URLs.
+
+7.2.  User Controls
+
+   User agents SHOULD provide users with a mechanism for managing the
+   cookies stored in the cookie store.  For example, a user agent might
+   let users delete all cookies received during a specified time period
+
+
+
+
+
+Barth                        Standards Track                   [Page 28]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   or all the cookies related to a particular domain.  In addition, many
+   user agents include a user interface element that lets users examine
+   the cookies stored in their cookie store.
+
+   User agents SHOULD provide users with a mechanism for disabling
+   cookies.  When cookies are disabled, the user agent MUST NOT include
+   a Cookie header in outbound HTTP requests and the user agent MUST NOT
+   process Set-Cookie headers in inbound HTTP responses.
+
+   Some user agents provide users the option of preventing persistent
+   storage of cookies across sessions.  When configured thusly, user
+   agents MUST treat all received cookies as if the persistent-flag were
+   set to false.  Some popular user agents expose this functionality via
+   "private browsing" mode [Aggarwal2010].
+
+   Some user agents provide users with the ability to approve individual
+   writes to the cookie store.  In many common usage scenarios, these
+   controls generate a large number of prompts.  However, some privacy-
+   conscious users find these controls useful nonetheless.
+
+7.3.  Expiration Dates
+
+   Although servers can set the expiration date for cookies to the
+   distant future, most user agents do not actually retain cookies for
+   multiple decades.  Rather than choosing gratuitously long expiration
+   periods, servers SHOULD promote user privacy by selecting reasonable
+   cookie expiration periods based on the purpose of the cookie.  For
+   example, a typical session identifier might reasonably be set to
+   expire in two weeks.
+
+8.  Security Considerations
+
+8.1.  Overview
+
+   Cookies have a number of security pitfalls.  This section overviews a
+   few of the more salient issues.
+
+   In particular, cookies encourage developers to rely on ambient
+   authority for authentication, often becoming vulnerable to attacks
+   such as cross-site request forgery [CSRF].  Also, when storing
+   session identifiers in cookies, developers often create session
+   fixation vulnerabilities.
+
+   Transport-layer encryption, such as that employed in HTTPS, is
+   insufficient to prevent a network attacker from obtaining or altering
+   a victim's cookies because the cookie protocol itself has various
+   vulnerabilities (see "Weak Confidentiality" and "Weak Integrity",
+
+
+
+
+Barth                        Standards Track                   [Page 29]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   below).  In addition, by default, cookies do not provide
+   confidentiality or integrity from network attackers, even when used
+   in conjunction with HTTPS.
+
+8.2.  Ambient Authority
+
+   A server that uses cookies to authenticate users can suffer security
+   vulnerabilities because some user agents let remote parties issue
+   HTTP requests from the user agent (e.g., via HTTP redirects or HTML
+   forms).  When issuing those requests, user agents attach cookies even
+   if the remote party does not know the contents of the cookies,
+   potentially letting the remote party exercise authority at an unwary
+   server.
+
+   Although this security concern goes by a number of names (e.g.,
+   cross-site request forgery, confused deputy), the issue stems from
+   cookies being a form of ambient authority.  Cookies encourage server
+   operators to separate designation (in the form of URLs) from
+   authorization (in the form of cookies).  Consequently, the user agent
+   might supply the authorization for a resource designated by the
+   attacker, possibly causing the server or its clients to undertake
+   actions designated by the attacker as though they were authorized by
+   the user.
+
+   Instead of using cookies for authorization, server operators might
+   wish to consider entangling designation and authorization by treating
+   URLs as capabilities.  Instead of storing secrets in cookies, this
+   approach stores secrets in URLs, requiring the remote entity to
+   supply the secret itself.  Although this approach is not a panacea,
+   judicious application of these principles can lead to more robust
+   security.
+
+8.3.  Clear Text
+
+   Unless sent over a secure channel (such as TLS), the information in
+   the Cookie and Set-Cookie headers is transmitted in the clear.
+
+   1.  All sensitive information conveyed in these headers is exposed to
+       an eavesdropper.
+
+   2.  A malicious intermediary could alter the headers as they travel
+       in either direction, with unpredictable results.
+
+   3.  A malicious client could alter the Cookie header before
+       transmission, with unpredictable results.
+
+
+
+
+
+
+Barth                        Standards Track                   [Page 30]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   Servers SHOULD encrypt and sign the contents of cookies (using
+   whatever format the server desires) when transmitting them to the
+   user agent (even when sending the cookies over a secure channel).
+   However, encrypting and signing cookie contents does not prevent an
+   attacker from transplanting a cookie from one user agent to another
+   or from replaying the cookie at a later time.
+
+   In addition to encrypting and signing the contents of every cookie,
+   servers that require a higher level of security SHOULD use the Cookie
+   and Set-Cookie headers only over a secure channel.  When using
+   cookies over a secure channel, servers SHOULD set the Secure
+   attribute (see Section 4.1.2.5) for every cookie.  If a server does
+   not set the Secure attribute, the protection provided by the secure
+   channel will be largely moot.
+
+   For example, consider a webmail server that stores a session
+   identifier in a cookie and is typically accessed over HTTPS.  If the
+   server does not set the Secure attribute on its cookies, an active
+   network attacker can intercept any outbound HTTP request from the
+   user agent and redirect that request to the webmail server over HTTP.
+   Even if the webmail server is not listening for HTTP connections, the
+   user agent will still include cookies in the request.  The active
+   network attacker can intercept these cookies, replay them against the
+   server, and learn the contents of the user's email.  If, instead, the
+   server had set the Secure attribute on its cookies, the user agent
+   would not have included the cookies in the clear-text request.
+
+8.4.  Session Identifiers
+
+   Instead of storing session information directly in a cookie (where it
+   might be exposed to or replayed by an attacker), servers commonly
+   store a nonce (or "session identifier") in a cookie.  When the server
+   receives an HTTP request with a nonce, the server can look up state
+   information associated with the cookie using the nonce as a key.
+
+   Using session identifier cookies limits the damage an attacker can
+   cause if the attacker learns the contents of a cookie because the
+   nonce is useful only for interacting with the server (unlike non-
+   nonce cookie content, which might itself be sensitive).  Furthermore,
+   using a single nonce prevents an attacker from "splicing" together
+   cookie content from two interactions with the server, which could
+   cause the server to behave unexpectedly.
+
+   Using session identifiers is not without risk.  For example, the
+   server SHOULD take care to avoid "session fixation" vulnerabilities.
+   A session fixation attack proceeds in three steps.  First, the
+   attacker transplants a session identifier from his or her user agent
+   to the victim's user agent.  Second, the victim uses that session
+
+
+
+Barth                        Standards Track                   [Page 31]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   identifier to interact with the server, possibly imbuing the session
+   identifier with the user's credentials or confidential information.
+   Third, the attacker uses the session identifier to interact with
+   server directly, possibly obtaining the user's authority or
+   confidential information.
+
+8.5.  Weak Confidentiality
+
+   Cookies do not provide isolation by port.  If a cookie is readable by
+   a service running on one port, the cookie is also readable by a
+   service running on another port of the same server.  If a cookie is
+   writable by a service on one port, the cookie is also writable by a
+   service running on another port of the same server.  For this reason,
+   servers SHOULD NOT both run mutually distrusting services on
+   different ports of the same host and use cookies to store security-
+   sensitive information.
+
+   Cookies do not provide isolation by scheme.  Although most commonly
+   used with the http and https schemes, the cookies for a given host
+   might also be available to other schemes, such as ftp and gopher.
+   Although this lack of isolation by scheme is most apparent in non-
+   HTTP APIs that permit access to cookies (e.g., HTML's document.cookie
+   API), the lack of isolation by scheme is actually present in
+   requirements for processing cookies themselves (e.g., consider
+   retrieving a URI with the gopher scheme via HTTP).
+
+   Cookies do not always provide isolation by path.  Although the
+   network-level protocol does not send cookies stored for one path to
+   another, some user agents expose cookies via non-HTTP APIs, such as
+   HTML's document.cookie API.  Because some of these user agents (e.g.,
+   web browsers) do not isolate resources received from different paths,
+   a resource retrieved from one path might be able to access cookies
+   stored for another path.
+
+8.6.  Weak Integrity
+
+   Cookies do not provide integrity guarantees for sibling domains (and
+   their subdomains).  For example, consider foo.example.com and
+   bar.example.com.  The foo.example.com server can set a cookie with a
+   Domain attribute of "example.com" (possibly overwriting an existing
+   "example.com" cookie set by bar.example.com), and the user agent will
+   include 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 cookie it set itself.  The foo.example.com server might be
+   able to leverage this ability to mount an attack against
+   bar.example.com.
+
+
+
+
+
+Barth                        Standards Track                   [Page 32]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   Even though the Set-Cookie header supports the Path attribute, the
+   Path attribute does not provide any integrity protection because the
+   user agent will accept an arbitrary Path attribute in a Set-Cookie
+   header.  For example, an HTTP response to a request for
+   http://example.com/foo/bar can set a cookie with a Path attribute of
+   "/qux".  Consequently, servers SHOULD NOT both run mutually
+   distrusting services on different paths of the same host and use
+   cookies to store security-sensitive information.
+
+   An active network attacker can also inject cookies into the Cookie
+   header sent to https://example.com/ by impersonating a response from
+   http://example.com/ and injecting a Set-Cookie header.  The HTTPS
+   server at example.com will be unable to distinguish these cookies
+   from cookies that it set itself in an HTTPS response.  An active
+   network attacker might be able to leverage this ability to mount an
+   attack against example.com even if example.com uses HTTPS
+   exclusively.
+
+   Servers can partially mitigate these attacks by encrypting and
+   signing the contents of their cookies.  However, using cryptography
+   does not mitigate the issue completely because an attacker can replay
+   a cookie he or she received from the authentic example.com server in
+   the user's session, with unpredictable results.
+
+   Finally, an attacker might be able to force the user agent to delete
+   cookies by storing a large number of cookies.  Once the user agent
+   reaches its storage limit, the user agent will be forced to evict
+   some cookies.  Servers SHOULD NOT rely upon user agents retaining
+   cookies.
+
+8.7.  Reliance on DNS
+
+   Cookies rely upon the Domain Name System (DNS) for security.  If the
+   DNS is partially or fully compromised, the cookie protocol might fail
+   to provide the security properties required by applications.
+
+9.  IANA Considerations
+
+   The permanent message header field registry (see [RFC3864]) has been
+   updated with the following registrations.
+
+
+
+
+
+
+
+
+
+
+
+Barth                        Standards Track                   [Page 33]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+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)
+
+9.3.  Cookie2
+
+   Header field name: Cookie2
+
+   Applicable protocol: http
+
+   Status: obsoleted
+
+   Author/Change controller: IETF
+
+   Specification document: [RFC2965]
+
+9.4.  Set-Cookie2
+
+   Header field name: Set-Cookie2
+
+   Applicable protocol: http
+
+   Status: obsoleted
+
+   Author/Change controller: IETF
+
+   Specification document: [RFC2965]
+
+
+
+
+Barth                        Standards Track                   [Page 34]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
+              and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
+              "Internationalizing Domain Names in Applications (IDNA)",
+              RFC 3490, March 2003.
+
+              See Section 6.3 for an explanation why the normative
+              reference to an obsoleted specification is needed.
+
+   [RFC4790]  Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
+              Application Protocol Collation Registry", RFC 4790,
+              March 2007.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [RFC5890]  Klensin, J., "Internationalized Domain Names for
+              Applications (IDNA): Definitions and Document Framework",
+              RFC 5890, August 2010.
+
+   [USASCII]  American National Standards Institute, "Coded Character
+              Set -- 7-bit American Standard Code for Information
+              Interchange", ANSI X3.4, 1986.
+
+10.2.  Informative References
+
+   [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
+              Mechanism", RFC 2109, February 1997.
+
+   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
+              Mechanism", RFC 2965, October 2000.
+
+
+
+
+
+Barth                        Standards Track                   [Page 35]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [Netscape] Netscape Communications Corp., "Persistent Client State --
+              HTTP Cookies", 1999, <http://web.archive.org/web/
+              20020803110822/http://wp.netscape.com/newsref/std/
+              cookie_spec.html>.
+
+   [Kri2001]  Kristol, D., "HTTP Cookies: Standards, Privacy, and
+              Politics", ACM Transactions on Internet Technology Vol. 1,
+              #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, October 2006.
+
+   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
+              Procedures for Message Header Fields", BCP 90, RFC 3864,
+              September 2004.
+
+   [RFC5895]  Resnick, P. and P. Hoffman, "Mapping Characters for
+              Internationalized Domain Names in Applications (IDNA)
+              2008", RFC 5895, September 2010.
+
+   [UTS46]    Davis, M. and M. Suignard, "Unicode IDNA Compatibility
+              Processing", Unicode Technical Standards # 46, 2010,
+              <http://unicode.org/reports/tr46/>.
+
+   [CSRF]     Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses
+              for Cross-Site Request Forgery", 2008,
+              <http://portal.acm.org/citation.cfm?id=1455770.1455782>.
+
+   [Aggarwal2010]
+              Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh,
+              "An Analysis of Private Browsing Modes in Modern
+              Browsers", 2010, <http://www.usenix.org/events/sec10/tech/
+              full_papers/Aggarwal.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barth                        Standards Track                   [Page 36]
+
+RFC 6265             HTTP State Management Mechanism          April 2011
+
+
+Appendix A.  Acknowledgements
+
+   This document borrows heavily from RFC 2109 [RFC2109].  We are
+   indebted to David M. Kristol and Lou Montulli for their efforts to
+   specify cookies.  David M. Kristol, in particular, provided
+   invaluable advice on navigating the IETF process.  We would also like
+   to thank Thomas Broyer, Tyler Close, Alissa Cooper, Bil Corry,
+   corvid, Lisa Dusseault, Roy T. Fielding, Blake Frantz, Anne van
+   Kesteren, Eran Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim
+   Hoffmann, Georg Koppen, Dean McNamee, Alexey Melnikov, Mark Miller,
+   Mark Pauley, Yngve N. Pettersen, Julian Reschke, Peter Saint-Andre,
+   Mark Seaborn, Maciej Stachowiak, Daniel Stenberg, Tatsuhiro
+   Tsujikawa, David Wagner, Dan Winship, and Dan Witte for their
+   valuable feedback on this document.
+
+Author's Address
+
+   Adam Barth
+   University of California, Berkeley
+
+   EMail: abarth@eecs.berkeley.edu
+   URI:   http://www.adambarth.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barth                        Standards Track                   [Page 37]
+