draft-ietf-httpbis-rfc6265bis-00.txt   draft-ietf-httpbis-rfc6265bis-latest.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 February 20, 2017
Expires: August 24, 2017
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-00 draft-ietf-httpbis-rfc6265bis-latest
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 August 24, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 5 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 6
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 8 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 9
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 10 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 11
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 14
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 14 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 15
5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 14 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 15
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . . 15 5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . . 16
5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 16 5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 17
5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . . 16 5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . . 17
5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 17 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 18
5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 18 5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 19
5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 19 5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 20
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 19 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 20
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 20 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 21
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 20 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 21
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 20 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 21
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 20 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 21
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 23 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 24
6. Implementation Considerations . . . . . . . . . . . . . . . . 24 6. Implementation Considerations . . . . . . . . . . . . . . . . 25
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. Application Programming Interfaces . . . . . . . . . . . . 25 6.2. Application Programming Interfaces . . . . . . . . . . . . 26
6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 25 6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 26
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 25 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 26
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 26 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 27
7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 26 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 27
7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . . 27 7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 27 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 28
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 28 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 29
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 29 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 30
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 29 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 30
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 30 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 31
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 31 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 32
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 31 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 32
9.3. Cookie2 . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.4. Set-Cookie2 . . . . . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 33 10.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 Appendix A. Changes since draft-ietf-httpbis-rfc6265bis-00 . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
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 27 skipping to change at page 10, 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 14, line 39 skipping to change at page 15, line 39
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
skipping to change at page 16, line 22 skipping to change at page 17, line 22
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. * The domain string is a suffix of the string.
o The last character of the string that is not included in the * The last character of the string that is not included in the
domain string is a %x2E (".") character. domain string is a %x2E (".") character.
o The string is a host name (i.e., not an IP address). * The string is a host name (i.e., not an IP address).
5.1.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 50 skipping to change at page 17, line 50
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 Section responses to "third-party" requests from setting cookies (see Section
skipping to change at page 31, line 21 skipping to change at page 32, line 21
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 Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document: this specification (Section 5.2) 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]
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 -
Application and Support", STD 3, RFC 1123, DOI 10.17487/ Application and Support", STD 3, RFC 1123, DOI 10.17487/
skipping to change at page 34, line 8 skipping to change at page 34, line 37
[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, 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629,
November 2003, <http://www.rfc-editor.org/info/rfc3629>. November 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 since draft-ietf-httpbis-rfc6265bis-00
o Fixes to formatting caused by mistakes in the initial port to
Markdown:
* https://github.com/httpwg/http-extensions/issues/243
o -01 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
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. 22 change blocks. 
91 lines changed or deleted 120 lines changed or added

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