draft-ietf-httpbis-rfc6265bis-00.txt   draft-ietf-httpbis-rfc6265bis-01.txt 
HTTP Working Group A. Barth HTTP Working Group A. Barth
Internet-Draft M. West Internet-Draft M. West
Intended status: Standards Track Google, Inc Obsoletes: 6265 (if approved) Google, Inc
Expires: April 13, 2017 October 10, 2016 Intended status: Standards Track April 25, 2017
Expires: October 27, 2017
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-00 draft-ietf-httpbis-rfc6265bis-01
Abstract Abstract
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
These header fields can be used by HTTP servers to store state These header fields can be used by HTTP servers to store state
(called cookies) at HTTP user agents, letting the servers maintain a (called cookies) at HTTP user agents, letting the servers maintain a
stateful session over the mostly stateless HTTP protocol. Although stateful session over the mostly stateless HTTP protocol. Although
cookies have many historical infelicities that degrade their security cookies have many historical infelicities that degrade their security
and privacy, the Cookie and Set-Cookie header fields are widely used and privacy, the Cookie and Set-Cookie header fields are widely used
on the Internet. This document obsoletes RFC 2965. on the Internet. This document obsoletes RFC 2965.
Note to Readers
Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/ .
Working Group information can be found at http://httpwg.github.io/ ;
source code and issues list for this draft can be found at
https://github.com/httpwg/http-extensions/labels/6265bis .
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 13, 2017. This Internet-Draft will expire on October 27, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . 4 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . 5
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 8 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 8
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 10 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 10
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 13
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 14
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 13 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 14 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 15
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 15
5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 15 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 16 5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 17
5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 16 5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 18
5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 17 5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 18
5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 18 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 19
5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 19 5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 21
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . 19 5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 21
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . 20 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . 22
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . 20 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . 22
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 20 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . 23
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 20 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 23
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 23 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 23
6. Implementation Considerations . . . . . . . . . . . . . . . . 25 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 27
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Implementation Considerations . . . . . . . . . . . . . . . . 29
6.2. Application Programming Interfaces . . . . . . . . . . . 25 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 26 6.2. Application Programming Interfaces . . . . . . . . . . . 29
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 30
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 26 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30
7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 27 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 30
7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . 27 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . 31
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 28 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 32
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 29 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 32
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 29 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 33
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 30 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 33
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 31 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 34
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 31 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 35
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 35
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 32 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.3. Cookie2 . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 36
9.4. Set-Cookie2 . . . . . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . 36
10.1. Normative References . . . . . . . . . . . . . . . . . . 32 10.2. Informative References . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . 33 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 39
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35 A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 39
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
Using the Set-Cookie header field, an HTTP server can pass name/value Using the Set-Cookie header field, an HTTP server can pass name/value
pairs and associated metadata (called cookies) to a user agent. When pairs and associated metadata (called cookies) to a user agent. When
the user agent makes subsequent requests to the server, the user the user agent makes subsequent requests to the server, the user
agent uses the metadata and other information to determine whether to agent uses the metadata and other information to determine whether to
return the name/value pairs in the Cookie header. return the name/value pairs in the Cookie header.
skipping to change at page 9, line 14 skipping to change at page 9, line 27
set-cookie-header = "Set-Cookie:" SP set-cookie-string set-cookie-header = "Set-Cookie:" SP set-cookie-string
set-cookie-string = cookie-pair *( ";" SP cookie-av ) set-cookie-string = cookie-pair *( ";" SP cookie-av )
cookie-pair = cookie-name "=" cookie-value cookie-pair = cookie-name "=" cookie-value
cookie-name = token cookie-name = token
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE ) cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
; US-ASCII characters excluding CTLs, ; US-ASCII characters excluding CTLs,
; whitespace DQUOTE, comma, semicolon, ; whitespace DQUOTE, comma, semicolon,
; and backslash ; and backslash
token = token token = <token, defined in [RFC2616], Section 2.2>
; defined in [RFC2616], Section 2.2
cookie-av = expires-av / max-age-av / domain-av / cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av / path-av / secure-av / httponly-av /
extension-av extension-av
expires-av = "Expires=" sane-cookie-date expires-av = "Expires=" sane-cookie-date
sane-cookie-date = rfc1123-date sane-cookie-date =
; defined in [RFC2616], Section 3.3.1 <rfc1123-date, defined in [RFC2616], Section 3.3.1>
max-age-av = "Max-Age=" non-zero-digit *DIGIT max-age-av = "Max-Age=" non-zero-digit *DIGIT
; In practice, both expires-av and max-age-av ; In practice, both expires-av and max-age-av
; are limited to dates representable by the ; are limited to dates representable by the
; user agent. ; user agent.
non-zero-digit = %x31-39 non-zero-digit = %x31-39
; digits 1 through 9 ; digits 1 through 9
domain-av = "Domain=" domain-value domain-av = "Domain=" domain-value
domain-value = <subdomain> domain-value = <subdomain>
; defined in [RFC1034], Section 3.5, as ; defined in [RFC1034], Section 3.5, as
; enhanced by [RFC1123], Section 2.1 ; enhanced by [RFC1123], Section 2.1
path-av = "Path=" path-value path-av = "Path=" path-value
path-value = <any CHAR except CTLs or ";"> path-value = *av-octet
secure-av = "Secure" secure-av = "Secure"
httponly-av = "HttpOnly" httponly-av = "HttpOnly"
extension-av = <any CHAR except CTLs or ";"> extension-av = *av-octet
av-octet = %x20-3A / %x3C-7E
; any CHAR except CTLs or ";"
Note that some of the grammatical terms above reference documents Note that some of the grammatical terms above reference documents
that use different grammatical notations than this document (which that use different grammatical notations than this document (which
uses ABNF from [RFC5234]). uses ABNF from [RFC5234]).
The semantics of the cookie-value are not defined by this document. The semantics of the cookie-value are not defined by this document.
To maximize compatibility with user agents, servers that wish to To maximize compatibility with user agents, servers that wish to
store arbitrary data in a cookie-value SHOULD encode that data, for store arbitrary data in a cookie-value SHOULD encode that data, for
example, using Base64 [RFC4648]. example, using Base64 [RFC4648].
skipping to change at page 13, line 9 skipping to change at page 13, line 16
The HttpOnly attribute limits the scope of the cookie to HTTP The HttpOnly attribute limits the scope of the cookie to HTTP
requests. In particular, the attribute instructs the user agent to requests. In particular, the attribute instructs the user agent to
omit the cookie when providing access to cookies via "non-HTTP" APIs omit the cookie when providing access to cookies via "non-HTTP" APIs
(such as a web browser API that exposes cookies to scripts). (such as a web browser API that exposes cookies to scripts).
Note that the HttpOnly attribute is independent of the Secure Note that the HttpOnly attribute is independent of the Secure
attribute: a cookie can have both the HttpOnly and the Secure attribute: a cookie can have both the HttpOnly and the Secure
attribute. attribute.
4.1.3. Cookie Name Prefixes
Section 8.5 and 8.6 of this document spell out some of the drawbacks
of cookies' historical implementation. In particular, it is
impossible for a server to have confidence that a given cookie was
set with a particular set of attributes. In order to provide such
confidence in a backwards-compatible way, two common sets of
requirements can be inferred from the first few characters of the
cookie's name.
The normative requirements for the prefixes described below are
detailed in the storage model algorithm defined in Section 5.3.
4.1.3.1. The "__Secure-" Prefix
If a cookie's name begins with a case-sensitive match for the string
"__Secure-", then the cookie will have been set with a "Secure"
attribute.
For example, the following "Set-Cookie" header would be rejected by a
conformant user agent, as it does not have a "Secure" attribute.
Set-Cookie: __Secure-SID=12345; Domain=example.com
Whereas the following "Set-Cookie" header would be accepted:
Set-Cookie: __Secure-SID=12345; Domain=example.com; Secure
4.1.3.2. The "__Host-" Prefix
If a cookie's name begins with a case-sensitive match for the string
"__Host-", then the cookie will have been set with a "Secure"
attribute, a "Path" attribute with a value of "/", and no "Domain"
attribute.
This combination yields a cookie that hews as closely as a cookie can
to treating the origin as a security boundary. The lack of a
"Domain" attribute ensures that the cookie's "host-only-flag" is
true, locking the cookie to a particular host, rather than allowing
it to span subdomains. Setting the "Path" to "/" means that the
cookie is effective for the entire host, and won't be overridden for
specific paths. The "Secure" attribute ensures that the cookie is
unaltered by non-secure origins, and won't span protocols.
Ports are the only piece of the origin model that "__Host-" cookies
continue to ignore.
For example, the following cookies would always be rejected:
Set-Cookie: __Host-SID=12345
Set-Cookie: __Host-SID=12345; Secure
Set-Cookie: __Host-SID=12345; Domain=example.com
Set-Cookie: __Host-SID=12345; Domain=example.com; Path=/
Set-Cookie: __Host-SID=12345; Secure; Domain=example.com; Path=/
While the would be accepted if set from a secure origin (e.g.
"https://example.com/"), and rejected otherwise:
Set-Cookie: __Host-SID=12345; Secure; Path=/
4.2. Cookie 4.2. Cookie
4.2.1. Syntax 4.2.1. Syntax
The user agent sends stored cookies to the origin server in the The user agent sends stored cookies to the origin server in the
Cookie header. If the server conforms to the requirements in Cookie header. If the server conforms to the requirements in
Section 4.1 (and the user agent 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 Section 5), the user agent will send a Cookie header that conforms to
the following grammar: the following grammar:
skipping to change at page 14, line 32 skipping to change at page 16, line 13
1. Using the grammar below, divide the cookie-date into date-tokens. 1. Using the grammar below, divide the cookie-date into date-tokens.
cookie-date = *delimiter date-token-list *delimiter cookie-date = *delimiter date-token-list *delimiter
date-token-list = date-token *( 1*delimiter date-token ) date-token-list = date-token *( 1*delimiter date-token )
date-token = 1*non-delimiter date-token = 1*non-delimiter
delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
non-digit = %x00-2F / %x3A-FF non-digit = %x00-2F / %x3A-FF
day-of-month = 1*2DIGIT ( non-digit *OCTET ) day-of-month = 1*2DIGIT [ non-digit *OCTET ]
month = ( "jan" / "feb" / "mar" / "apr" / month = ( "jan" / "feb" / "mar" / "apr" /
"may" / "jun" / "jul" / "aug" / "may" / "jun" / "jul" / "aug" /
"sep" / "oct" / "nov" / "dec" ) *OCTET "sep" / "oct" / "nov" / "dec" ) *OCTET
year = 2*4DIGIT ( non-digit *OCTET ) year = 2*4DIGIT [ non-digit *OCTET ]
time = hms-time ( non-digit *OCTET ) time = hms-time [ non-digit *OCTET ]
hms-time = time-field ":" time-field ":" time-field hms-time = time-field ":" time-field ":" time-field
time-field = 1*2DIGIT time-field = 1*2DIGIT
2. Process each date-token sequentially in the order the date-tokens 2. Process each date-token sequentially in the order the date-tokens
appear in the cookie-date: appear in the cookie-date:
1. If the found-time flag is not set and the token matches the 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- time production, set the found-time flag and set the hour-
value, minute-value, and second-value to the numbers denoted value, minute-value, and second-value to the numbers denoted
by the digits in the date-token, respectively. Skip the by the digits in the date-token, respectively. Skip the
remaining sub-steps and continue to the next date-token. 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 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- matches the day-of-month production, set the found-day-of-
month flag and set the day-of-month-value to the number month flag and set the day-of-month-value to the number
denoted by the date-token. Skip the remaining sub-steps and denoted by the date-token. Skip the remaining sub-steps and
continue to the next date-token. continue to the next date-token.
3. If the found-month flag is not set and the date-token matches 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 the month production, set the found-month flag and set the
month-value to the month denoted by the date-token. Skip the month-value to the month denoted by the date-token. Skip the
remaining sub-steps and continue to the next date-token. remaining sub-steps and continue to the next date-token.
4. If the found-year flag is not set and the date-token matches 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 the year production, set the found-year flag and set the
year-value to the number denoted by the date-token. Skip the year-value to the number denoted by the date-token. Skip the
remaining sub-steps and continue to the next date-token. 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 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. 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 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. equal to 69, increment the year-value by 2000.
1. NOTE: Some existing user agents interpret two-digit years 1. NOTE: Some existing user agents interpret two-digit years
differently. differently.
5. Abort these steps and fail to parse the cookie-date if: 5. Abort these steps and fail to parse the cookie-date if:
* at least one of the found-day-of-month, found-month, found- * at least one of the found-day-of-month, found-month, found-
year, or found-time flags is not set, year, or found-time flags is not set,
* the day-of-month-value is less than 1 or greater than 31, * the day-of-month-value is less than 1 or greater than 31,
* the year-value is less than 1601, * the year-value is less than 1601,
* the hour-value is greater than 23, * the hour-value is greater than 23,
* the minute-value is greater than 59, or * the minute-value is greater than 59, or
* the second-value is greater than 59. * the second-value is greater than 59.
(Note that leap seconds cannot be represented in this syntax.) (Note that leap seconds cannot be represented in this syntax.)
6. Let the parsed-cookie-date be the date whose day-of-month, month, 6. Let the parsed-cookie-date be the date whose day-of-month, month,
year, hour, minute, and second (in UTC) are the day-of-month- year, hour, minute, and second (in UTC) are the day-of-month-
value, the month-value, the year-value, the hour-value, the value, the month-value, the year-value, the hour-value, the
minute-value, and the second-value, respectively. If no such minute-value, and the second-value, respectively. If no such
date exists, abort these steps and fail to parse the cookie-date. date exists, abort these steps and fail to parse the cookie-date.
7. Return the parsed-cookie-date as the result of this algorithm. 7. Return the parsed-cookie-date as the result of this algorithm.
5.1.2. Canonicalized Host Names 5.1.2. Canonicalized Host Names
A canonicalized host name is the string generated by the following A canonicalized host name is the string generated by the following
algorithm: algorithm:
1. Convert the host name to a sequence of individual domain name 1. Convert the host name to a sequence of individual domain name
labels. labels.
2. Convert each label that is not a Non-Reserved LDH (NR-LDH) label, 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 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 and latter), or to a "punycode label" (a label resulting from the
"ToASCII" conversion in Section 4 of [RFC3490]), as appropriate "ToASCII" conversion in Section 4 of [RFC3490]), as appropriate
(see Section 6.3 of this specification). (see Section 6.3 of this specification).
3. Concatenate the resulting labels, separated by a %x2E (".") 3. Concatenate the resulting labels, separated by a %x2E (".")
character. character.
5.1.3. Domain Matching 5.1.3. Domain Matching
skipping to change at page 16, line 16 skipping to change at page 18, line 13
character. character.
5.1.3. Domain Matching 5.1.3. Domain Matching
A string domain-matches a given domain string if at least one of the A string domain-matches a given domain string if at least one of the
following conditions hold: following conditions hold:
o The domain string and the string are identical. (Note that both o The domain string and the string are identical. (Note that both
the domain string and the string will have been canonicalized to the domain string and the string will have been canonicalized to
lower case at this point.) lower case at this point.)
o All of the following conditions hold: o All of the following conditions hold:
o The domain string is a suffix of the string.
o The last character of the string that is not included in the * The domain string is a suffix of the string.
domain string is a %x2E (".") character.
o The string is a host name (i.e., not an IP address). * 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 5.1.4. Paths and Path-Match
The user agent MUST use an algorithm equivalent to the following The user agent MUST use an algorithm equivalent to the following
algorithm to compute the default-path of a cookie: algorithm to compute the default-path of a cookie:
1. Let uri-path be the path portion of the request-uri if such a 1. Let uri-path be the path portion of the request-uri if such a
portion exists (and empty otherwise). For example, if the portion exists (and empty otherwise). For example, if the
request-uri contains just a path (and optional query string), request-uri contains just a path (and optional query string),
then the uri-path is that path (without the %x3F ("?") character then the uri-path is that path (without the %x3F ("?") character
skipping to change at page 16, line 33 skipping to change at page 18, line 34
The user agent MUST use an algorithm equivalent to the following The user agent MUST use an algorithm equivalent to the following
algorithm to compute the default-path of a cookie: algorithm to compute the default-path of a cookie:
1. Let uri-path be the path portion of the request-uri if such a 1. Let uri-path be the path portion of the request-uri if such a
portion exists (and empty otherwise). For example, if the portion exists (and empty otherwise). For example, if the
request-uri contains just a path (and optional query string), request-uri contains just a path (and optional query string),
then the uri-path is that path (without the %x3F ("?") character then the uri-path is that path (without the %x3F ("?") character
or query string), and if the request-uri contains a full or query string), and if the request-uri contains a full
absoluteURI, the uri-path is the path component of that URI. 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- 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 path is not a %x2F ("/") character, output %x2F ("/") and skip
the remaining steps. the remaining steps.
3. If the uri-path contains no more than one %x2F ("/") character, 3. If the uri-path contains no more than one %x2F ("/") character,
output %x2F ("/") and skip the remaining step. output %x2F ("/") and skip the remaining step.
4. Output the characters of the uri-path from the first character up 4. Output the characters of the uri-path from the first character up
to, but not including, the right-most %x2F ("/"). to, but not including, the right-most %x2F ("/").
A request-path path-matches a given cookie-path if at least one of A request-path path-matches a given cookie-path if at least one of
the following conditions holds: the following conditions holds:
o The cookie-path and the request-path are identical. o The cookie-path and the request-path are identical.
Note that this differs from the rules in [RFC3986] for equivalence
of the path component, and hence two equivalent paths can have
different cookies.
o The cookie-path is a prefix of the request-path, and the last o The cookie-path is a prefix of the request-path, and the last
character of the cookie-path is %x2F ("/"). character of the cookie-path is %x2F ("/").
o The cookie-path is a prefix of the request-path, and the first o The cookie-path is a prefix of the request-path, and the first
character of the request-path that is not included in the cookie- character of the request-path that is not included in the cookie-
path is a %x2F ("/") character. path is a %x2F ("/") character.
5.2. The Set-Cookie Header 5.2. The Set-Cookie Header
When a user agent receives a Set-Cookie header field in an HTTP When a user agent receives a Set-Cookie header field in an HTTP
response, the user agent MAY ignore the Set-Cookie header field in response, the user agent MAY ignore the Set-Cookie header field in
its entirety. For example, the user agent might wish to block its entirety. For example, the user agent might wish to block
responses to "third-party" requests from setting cookies (see responses to "third-party" requests from setting cookies (see
skipping to change at page 22, line 24 skipping to change at page 25, line 10
6. If the domain-attribute is non-empty: 6. If the domain-attribute is non-empty:
1. If the canonicalized request-host does not domain-match the 1. If the canonicalized request-host does not domain-match the
domain-attribute: domain-attribute:
1. Ignore the cookie entirely and abort these steps. 1. Ignore the cookie entirely and abort these steps.
Otherwise: Otherwise:
1. Set the cookie's host-only-flag to false. 1. Set the cookie's host-only-flag to false.
2. Set the cookie's domain to the domain-attribute. 2. Set the cookie's domain to the domain-attribute.
Otherwise: Otherwise:
1. Set the cookie's host-only-flag to true. 1. Set the cookie's host-only-flag to true.
2. Set the cookie's domain to the canonicalized request-host. 2. Set the cookie's domain to the canonicalized request-host.
7. If the cookie-attribute-list contains an attribute with an 7. If the cookie-attribute-list contains an attribute with an
attribute-name of "Path", set the cookie's path to attribute- attribute-name of "Path", set the cookie's path to attribute-
value of the last attribute in the cookie-attribute-list with an value of the last attribute in the cookie-attribute-list with an
attribute-name of "Path". Otherwise, set the cookie's path to attribute-name of "Path". Otherwise, set the cookie's path to
the default-path of the request-uri. the default-path of the request-uri.
8. If the cookie-attribute-list contains an attribute with an 8. If the cookie-attribute-list contains an attribute with an
attribute-name of "Secure", set the cookie's secure-only-flag to attribute-name of "Secure", set the cookie's secure-only-flag to
true. Otherwise, set the cookie's secure-only-flag to false. true. Otherwise, set the cookie's secure-only-flag to false.
9. If the cookie-attribute-list contains an attribute with an
9. If the scheme component of the request-uri does not denote a
"secure" protocol (as defined by the user agent), and the
cookie's secure-only-flag is true, then abort these steps and
ignore the cookie entirely.
10. If the cookie-attribute-list contains an attribute with an
attribute-name of "HttpOnly", set the cookie's http-only-flag to attribute-name of "HttpOnly", set the cookie's http-only-flag to
true. Otherwise, set the cookie's http-only-flag to false. true. Otherwise, set the cookie's http-only-flag to false.
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 11. If the cookie was received from a "non-HTTP" API and the
cookie entirely. cookie's http-only-flag is true, abort these steps and ignore
11. If the cookie store contains a cookie with the same name, the cookie entirely.
domain, and path as the newly created cookie:
12. If the cookie's secure-only-flag is not set, and the scheme
component of request-uri does not denote a "secure" protocol,
then abort these steps and ignore the cookie entirely if the
cookie store contains one or more cookies that meet all of the
following criteria:
1. Their name matches the name of the newly-created cookie.
2. Their secure-only-flag is true.
3. Their domain domain-matches the domain of the newly-created
cookie, or vice-versa.
4. The path of the newly-created cookie path-matches the path
of the existing cookie.
Note: The path comparison is not symmetric, ensuring only that a
newly-created, non-secure cookie does not overlay an existing
secure cookie, providing some mitigation against cookie-fixing
attacks. That is, given an existing secure cookie named 'a'
with a path of '/login', a non-secure cookie named 'a' could be
set for a path of '/' or '/foo', but not for a path of '/login'
or '/login/en'.
13. If the cookie-name begins with a case-sensitive match for the
string "__Secure-", abort these steps and ignore the cookie
entirely unless the cookie's secure-only-flag is true.
14. If the cookie-name begins with a case-sensitive match for the
string "__Host-", abort these steps and ignore the cookie
entirely unless the cookie meets all the following criteria:
1. The cookie's secure-only-flag is true.
2. The cookie's host-only-flag is true.
3. The cookie's path is "/".
15. 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, 1. Let old-cookie be the existing cookie with the same name,
domain, and path as the newly created cookie. (Notice that domain, and path as the newly-created cookie. (Notice that
this algorithm maintains the invariant that there is at most this algorithm maintains the invariant that there is at most
one such cookie.) one such cookie.)
2. If the newly created cookie was received from a "non-HTTP" 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 API and the old-cookie's http-only-flag is true, abort these
steps and ignore the newly created cookie entirely. steps and ignore the newly created cookie entirely.
3. Update the creation-time of the newly created cookie to
3. Update the creation-time of the newly-created cookie to
match the creation-time of the old-cookie. match the creation-time of the old-cookie.
4. Remove the old-cookie from the cookie store. 4. Remove the old-cookie from the cookie store.
12. Insert the newly created cookie into the cookie store.
16. Insert the newly-created cookie into the cookie store.
A cookie is "expired" if the cookie has an expiry date in the past. A cookie is "expired" if the cookie has an expiry date in the past.
The user agent MUST evict all expired cookies from the cookie store The user agent MUST evict all expired cookies from the cookie store
if, at any time, an expired cookie exists in the cookie store. if, at any time, an expired cookie exists in the cookie store.
At any time, the user agent MAY "remove excess cookies" from the At any time, the user agent MAY "remove excess cookies" from the
cookie store if the number of cookies sharing a domain field exceeds cookie store if the number of cookies sharing a domain field exceeds
some implementation-defined upper bound (such as 50 cookies). some implementation-defined upper bound (such as 50 cookies).
At any time, the user agent MAY "remove excess cookies" from the At any time, the user agent MAY "remove excess cookies" from the
cookie store if the cookie store exceeds some predetermined upper cookie store if the cookie store exceeds some predetermined upper
bound (such as 3000 cookies). bound (such as 3000 cookies).
When the user agent removes excess cookies from the cookie store, the When the user agent removes excess cookies from the cookie store, the
user agent MUST evict cookies in the following priority order: user agent MUST evict cookies in the following priority order:
1. Expired cookies. 1. Expired cookies.
2. Cookies that share a domain field with more than a predetermined
2. Cookies whose secure-only-flag is not set, and which share a
domain field with more than a predetermined number of other
cookies.
3. Cookies that share a domain field with more than a predetermined
number of other cookies. number of other cookies.
3. All cookies.
4. All cookies.
If two cookies have the same removal priority, the user agent MUST If two cookies have the same removal priority, the user agent MUST
evict the cookie with the earliest last-access date first. evict the cookie with the earliest last-access date first.
When "the current session is over" (as defined by the user agent), When "the current session is over" (as defined by the user agent),
the user agent MUST remove from the cookie store all cookies with the the user agent MUST remove from the cookie store all cookies with the
persistent-flag set to false. persistent-flag set to false.
5.4. The Cookie Header 5.4. The Cookie Header
skipping to change at page 32, line 7 skipping to change at page 36, line 7
cookies. cookies.
8.7. Reliance on DNS 8.7. Reliance on DNS
Cookies rely upon the Domain Name System (DNS) for security. If the Cookies rely upon the Domain Name System (DNS) for security. If the
DNS is partially or fully compromised, the cookie protocol might fail DNS is partially or fully compromised, the cookie protocol might fail
to provide the security properties required by applications. to provide the security properties required by applications.
9. IANA Considerations 9. IANA Considerations
The permanent message header field registry (see [RFC3864]) has been The permanent message header field registry (see [RFC3864]) needs to
updated with the following registrations. be updated with the following registrations.
9.1. Cookie 9.1. Cookie
Header field name: Cookie Header field name: Cookie
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document: this specification (Section 5.4) Specification document: this specification (Section 5.4)
9.2. Set-Cookie 9.2. Set-Cookie
Header field name: 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 Applicable protocol: http
Status: obsoleted
Author/Change controller: IETF
Specification document: [RFC2965]
9.4. Set-Cookie2 Status: standard
Header field name: Set-Cookie2
Applicable protocol: http
Status: obsoleted
Author/Change controller: IETF Author/Change controller: IETF
Specification document: [RFC2965]
Specification document: this specification (Section 5.2)
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
skipping to change at page 33, line 41 skipping to change at page 37, line 31
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>. <http://www.rfc-editor.org/info/rfc5890>.
[USASCII] "Coded Character Set -- 7-bit American Standard Code for [USASCII] Institute, A., "Coded Character Set -- 7-bit American
Information Interchange", 1986, <ANSI X3.4>. Standard Code for Information Interchange", 1986, <ANSI
X3.4>.
10.2. Informative References 10.2. Informative References
[Aggarwal2010] [Aggarwal2010]
Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh, Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh,
"An Analysis of Private Browsing Modes in Modern "An Analysis of Private Browsing Modes in Modern
Browsers", 2010, Browsers", 2010,
<http://www.usenix.org/events/sec10/tech/full_papers/ <http://www.usenix.org/events/sec10/tech/full_papers/
Aggarwal.pdf>. Aggarwal.pdf>.
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses [CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses
for Cross-Site Request Forgery", 2008, for Cross-Site Request Forgery", 2008,
<http://portal.acm.org/citation.cfm?id=1455770.1455782>. <http://portal.acm.org/citation.cfm?id=1455770.1455782>.
[draft-ietf-httpbis-cookie-alone]
West, M., "Deprecate modification of 'secure' cookies from
non-secure origins", September 2016,
<https://tools.ietf.org/html/draft-ietf-httpbis-cookie-
alone-01>.
[draft-ietf-httpbis-cookie-prefixes]
West, M., "Cookie Prefixes", February 2016,
<https://tools.ietf.org/html/draft-ietf-httpbis-cookie-
prefixes-00>.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM ACM Transactions on Internet Technology Politics", ACM ACM Transactions on Internet Technology
Vol. 1, #2, November 2001, Vol. 1, #2, November 2001,
<http://arxiv.org/abs/cs.SE/0105018>. <http://arxiv.org/abs/cs.SE/0105018>.
[Netscape] [Netscape]
"Persistent Client State -- HTTP Cookies", 1999, <http://w Corp., N., "Persistent Client State -- HTTP Cookies",
eb.archive.org/web/20020803110822/http://wp.netscape.com/n 1999, <http://web.archive.org/web/20020803110822/http://wp
ewsref/std/cookie_spec.html>. .netscape.com/newsref/std/cookie_spec.html>.
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, DOI 10.17487/RFC2109, February 1997, Mechanism", RFC 2109, DOI 10.17487/RFC2109, February 1997,
<http://www.rfc-editor.org/info/rfc2109>. <http://www.rfc-editor.org/info/rfc2109>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
skipping to change at page 34, line 40 skipping to change at page 38, line 41
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004, DOI 10.17487/RFC3864, September 2004,
<http://www.rfc-editor.org/info/rfc3864>. <http://www.rfc-editor.org/info/rfc3864>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>. <http://www.rfc-editor.org/info/rfc4648>.
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for
Internationalized Domain Names in Applications (IDNA) Internationalized Domain Names in Applications (IDNA)
2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010,
<http://www.rfc-editor.org/info/rfc5895>. <http://www.rfc-editor.org/info/rfc5895>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>.
[UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility
Processing", UNICODE Unicode Technical Standards # 46, Processing", UNICODE Unicode Technical Standards # 46,
2010, <http://unicode.org/reports/tr46/>. 2010, <http://unicode.org/reports/tr46/>.
Appendix A. Acknowledgements Appendix A. Changes
A.1. draft-ietf-httpbis-rfc6265bis-00
o Port [RFC6265] to Markdown. No (intentional) normative changes.
A.2. draft-ietf-httpbis-rfc6265bis-01
o Fixes to formatting caused by mistakes in the initial port to
Markdown:
* https://github.com/httpwg/http-extensions/issues/243
* https://github.com/httpwg/http-extensions/issues/246
o Addresses errata 3444 by updating the "path-value" and "extension-
av" grammar, errata 4148 by updating the "day-of-month", "year",
and "time" grammar, and errata 3663 by adding the requested note.
https://www.rfc-editor.org/errata_search.php?rfc=6265
o Dropped "Cookie2" and "Set-Cookie2" from the IANA Considerations
section: https://github.com/httpwg/http-extensions/issues/247
o Merged the recommendations from [draft-ietf-httpbis-cookie-alone],
removing the ability for a non-secure origin to set cookies with a
'secure' flag, and to overwrite cookies whose 'secure' flag is
true.
o Merged the recommendations from
[draft-ietf-httpbis-cookie-prefixes], adding "__Secure-" and
"__Host-" cookie name prefix processing instructions.
Appendix B. Acknowledgements
This document is a minor update of RFC 6265, adding small features, This document is a minor update of RFC 6265, adding small features,
and aligning the specification with the reality of today's and aligning the specification with the reality of today's
deployments. Here, we're standing upon the shoulders of giants. deployments. Here, we're standing upon the shoulders of giants.
Authors' Addresses Authors' Addresses
Adam Barth Adam Barth
Google, Inc Google, Inc
 End of changes. 70 change blocks. 
104 lines changed or deleted 322 lines changed or added

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