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]
`
`Google Ex. 1011, pg 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]
`
`Google Ex. 1011, pg 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]
`
`Google Ex. 1011, pg 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]
`
`Google Ex. 1011, pg 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]
`
`Google Ex. 1011, pg 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]
`
`Google Ex. 1011, pg 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]
`
`Google Ex. 1011, pg 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]
`
`Google Ex. 1011, pg 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]
`
`Google Ex. 1011, pg 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]
`
`Google Ex. 1011, pg 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]
`
`Google Ex. 1011, pg 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]
`
`Google Ex. 1011, pg 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]
`
`Google Ex. 1011, pg 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]
`
`Google Ex. 1011, pg 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