draft-ietf-httpstate-cookie-18.txt   draft-ietf-httpstate-cookie-19.txt 
httpstate A. Barth httpstate A. Barth
Internet-Draft U.C. Berkeley Internet-Draft U.C. Berkeley
Obsoletes: 2965 (if approved) November 9, 2010 Obsoletes: 2965 (if approved) December 3, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: May 13, 2011 Expires: June 6, 2011
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpstate-cookie-18 draft-ietf-httpstate-cookie-19
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. on the Internet.
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 May 13, 2011. This Internet-Draft will expire on June 6, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents 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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 6 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 7
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 11 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 12
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 12 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 13
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 15 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 16 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 17
5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 16 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 17
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. Canonicalized host names . . . . . . . . . . . . . . . 18 5.1.2. Canonicalized host names . . . . . . . . . . . . . . . 19
5.1.3. Domain matching . . . . . . . . . . . . . . . . . . . 18 5.1.3. Domain matching . . . . . . . . . . . . . . . . . . . 19
5.1.4. Paths and path-match . . . . . . . . . . . . . . . . . 18 5.1.4. Paths and path-match . . . . . . . . . . . . . . . . . 19
5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 19 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 20
5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 21 5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 22
5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 21 5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 22
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 22 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 23
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 22 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 23
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 23 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 24
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 23 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 24
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 23 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 24
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 26 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 27
6. Implementation Considerations . . . . . . . . . . . . . . . . 29 6. Implementation Considerations . . . . . . . . . . . . . . . . 30
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Application Programming Interfaces . . . . . . . . . . . . 29 6.2. Application Programming Interfaces . . . . . . . . . . . . 30
6.3. IDNA dependency and migration . . . . . . . . . . . . . . 29 6.3. IDNA dependency and migration . . . . . . . . . . . . . . 30
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 31 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 32
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 31 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 32
7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 31 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 33 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 34
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 34 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 35
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 34 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 35
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 35 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 36
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 35 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 36
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 36 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 37
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 37 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 10.1. Normative References . . . . . . . . . . . . . . . . . . . 39
10.2. Informative References . . . . . . . . . . . . . . . . . . 38 10.2. Informative References . . . . . . . . . . . . . . . . . . 39
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 42
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 5, line 38 skipping to change at page 5, line 38
ports. ports.
Prior to this document, there were at least three descriptions of Prior to this document, there were at least three descriptions of
cookies: the so-called "Netscape cookie specification" [Netscape], cookies: the so-called "Netscape cookie specification" [Netscape],
RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these
documents describe how the Cookie and Set-Cookie headers are actually documents describe how the Cookie and Set-Cookie headers are actually
used on the Internet (see [Kri2001] for historical context). This used on the Internet (see [Kri2001] for historical context). This
document attempts to specify the syntax and semantics of these document attempts to specify the syntax and semantics of these
headers as they are actually used on the Internet. 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, but neither does it recommend all of the
syntactic and semantic variations in use today. The recommendations
in this document represent a preferred subset of current behaviors.
Where some existing software differs from the recommended protocol
in significant ways, the document contains a note explaining the
difference.
Therefore, in relation to previous IETF specifications of HTTP state Therefore, in relation to previous IETF specifications of HTTP state
management mechanisms, this document requests the following actions: management mechanisms, this document requests the following actions:
1. Change the status of [RFC2109] to Historic (it has already been 1. Change the status of [RFC2109] to Historic (it has already been
obsoleted by [RFC2965]). obsoleted by [RFC2965]).
2. Change the status of [RFC2965] to Historic. 2. Change the status of [RFC2965] to Historic.
3. Indicate that [RFC2965] is obsoleted by this document. 3. Indicate that [RFC2965] is 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. Conventions
2.1. Conformance Criteria 2.1. Conformance Criteria
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Requirements phrased in the imperative as part of algorithms (such as Requirements phrased in the imperative as part of algorithms (such as
"strip any leading space characters" or "return false and abort these "strip any leading space characters" or "return false and abort these
skipping to change at page 8, line 22 skipping to change at page 9, line 22
HTTP response. In subsequent requests, the user agent returns a HTTP response. In subsequent requests, the user agent returns a
Cookie request header to the origin server. The Cookie header Cookie request header to the origin server. The Cookie header
contains cookies the user agent received in previous Set-Cookie contains cookies the user agent received in previous Set-Cookie
headers. The origin server is free to ignore the Cookie header or headers. The origin server is free to ignore the Cookie header or
use its contents for an application-defined purpose. use its contents for an application-defined purpose.
Origin servers can send a Set-Cookie response header with any Origin servers can send a Set-Cookie response header with any
response. An origin server can include multiple Set-Cookie header response. An origin server can include multiple Set-Cookie header
fields in a single response. fields in a single response.
Note that folding multiple Set-Cookie header fields into a single Origin servers SHOULD NOT fold multiple Set-Cookie header fields into
header field might change the semantics of the header because the a single header field. The usual mechanism for folding HTTP headers
%x2C (",") character is used by the Set-Cookie header in a way that fields (i.e., as defined in [RFC2616]) might change the semantics of
conflicts with such folding. This historical infelicity is the Set-Cookie header field because the %x2C (",") character is used
incompatible with the usual mechanism for folding HTTP headers as by Set-Cookie in a way that conflicts with such folding.
defined in [RFC2616].
3.1. Examples 3.1. Examples
Using the Set-Cookie header, a server can send the user agent a short 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 string in an HTTP response that the user agent will return in future
HTTP requests. For example, the server can send the user agent a HTTP requests that are within the scope of the cookie. For example,
"session identifier" named SID with the value 31d4d96e407aad42. The the server can send the user agent a "session identifier" named SID
user agent then returns the session identifier in subsequent with the value 31d4d96e407aad42. The user agent then returns the
requests. session identifier in subsequent requests.
== Server -> User Agent == == Server -> User Agent ==
Set-Cookie: SID=31d4d96e407aad42 Set-Cookie: SID=31d4d96e407aad42
== User Agent -> Server == == User Agent -> Server ==
Cookie: SID=31d4d96e407aad42 Cookie: SID=31d4d96e407aad42
The server can alter the default scope of the cookie using the Path The server can alter the default scope of the cookie using the Path
skipping to change at page 13, line 6 skipping to change at page 14, line 6
the user agent makes an HTTP request, the user agent includes the the user agent makes an HTTP request, the user agent includes the
applicable, non-expired cookies in the Cookie header. applicable, non-expired cookies in the Cookie header.
If the user agent receives a new cookie with the same cookie-name, 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, domain-value, and path-value as a cookie that it has already stored,
the existing cookie is evicted and replaced with the new cookie. the existing cookie is evicted and replaced with the new cookie.
Notice that servers can delete cookies by sending the user agent a Notice that servers can delete cookies by sending the user agent a
new cookie with an Expires attribute with a value in the past. new cookie with an Expires attribute with a value in the past.
Unless the cookie's attributes indicate otherwise, the cookie is Unless the cookie's attributes indicate otherwise, the cookie is
returned only to the origin server, and it expires at the end of the returned only to the origin server (and not, e.g., to any
current session (as defined by the user agent). User agents ignore subdomains), and it expires at the end of the current session (as
unrecognized cookie attributes (but not the entire cookie). defined by the user agent). User agents ignore unrecognized cookie
attributes (but not the entire cookie).
4.1.2.1. The Expires Attribute 4.1.2.1. The Expires Attribute
The Expires attribute indicates the maximum lifetime of the cookie, The Expires attribute indicates the maximum lifetime of the cookie,
represented as the date and time at which the cookie expires. The represented as the date and time at which the cookie expires. The
user agent is not required to retain the cookie until the specified user agent is not required to retain the cookie until the specified
date has passed. In fact, user agents often evict cookies due to date has passed. In fact, user agents often evict cookies due to
memory pressure or privacy concerns. memory pressure or privacy concerns.
4.1.2.2. The Max-Age Attribute 4.1.2.2. The Max-Age Attribute
skipping to change at page 15, line 7 skipping to change at page 16, line 7
cookies from an insecure channel, disrupting their integrity (see cookies from an insecure channel, disrupting their integrity (see
Section 8.6 for more details). Section 8.6 for more details).
4.1.2.6. The HttpOnly Attribute 4.1.2.6. The HttpOnly Attribute
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
attribute: a cookie can have both the HttpOnly and the Secure
attribute.
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 16, line 22 skipping to change at page 17, line 22
5.1. Subcomponent Algorithms 5.1. Subcomponent Algorithms
This section defines some algorithms used by user agents to process This section defines some algorithms used by user agents to process
specific subcomponents of the Cookie and Set-Cookie headers. specific subcomponents of the Cookie and Set-Cookie headers.
5.1.1. Dates 5.1.1. Dates
The user agent MUST use an algorithm equivalent to the following The user agent MUST use an algorithm equivalent to the following
algorithm to parse a cookie-date. Note that the various boolean algorithm to parse a cookie-date. Note that the various boolean
flags defined as a part of the algorithm are initially "not set". 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. 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
skipping to change at page 33, line 14 skipping to change at page 34, line 14
8. Security Considerations 8. Security Considerations
8.1. Overview 8.1. Overview
Cookies have a number of security pitfalls. This section overviews a Cookies have a number of security pitfalls. This section overviews a
few of the more salient issues. few of the more salient issues.
In particular, cookies encourage developers to rely on ambient In particular, cookies encourage developers to rely on ambient
authority for authentication, often becoming vulnerable to attacks authority for authentication, often becoming vulnerable to attacks
such as cross-site request forgery. Also, when storing session such as cross-site request forgery [CSRF]. Also, when storing
identifiers in cookies, developers often create session fixation session identifiers in cookies, developers often create session
vulnerabilities. fixation vulnerabilities.
Transport-layer encryption, such as that employed in HTTPS, is Transport-layer encryption, such as that employed in HTTPS, is
insufficient to prevent a network attacker from obtaining or altering insufficient to prevent a network attacker from obtaining or altering
a victim's cookies because the cookie protocol itself has various a victim's cookies because the cookie protocol itself has various
vulnerabilities (see "Weak Confidentiality" and "Weak Integrity", vulnerabilities (see "Weak Confidentiality" and "Weak Integrity",
below). In addition, by default, cookies do not provide below). In addition, by default, cookies do not provide
confidentiality or integrity from network attackers, even when used confidentiality or integrity from network attackers, even when used
in conjunction with HTTPS. in conjunction with HTTPS.
8.2. Ambient Authority 8.2. Ambient Authority
skipping to change at page 40, line 5 skipping to change at page 40, line 32
September 2004. September 2004.
[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, September 2010. 2008", RFC 5895, September 2010.
[UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility
Processing", Unicode Technical Standards # 46, 2010, Processing", Unicode Technical Standards # 46, 2010,
<http://unicode.org/reports/tr46/>. <http://unicode.org/reports/tr46/>.
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses
for Cross-Site Request Forgery", 2008, <http://
www.adambarth.com/papers/2008/
barth-jackson-mitchell-b.pdf>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
This document borrows heavily from RFC 2109 [RFC2109]. We are This document borrows heavily from RFC 2109 [RFC2109]. We are
indebted to David M. Kristol and Lou Montulli for their efforts to indebted to David M. Kristol and Lou Montulli for their efforts to
specify cookies. David M. Kristol, in particular, provided specify cookies. David M. Kristol, in particular, provided
invaluable advice on navigating the IETF process. We would also like invaluable advice on navigating the IETF process. We would also like
to thank Thomas Broyer, Tyler Close, Bil Corry, corvid, Lisa to thank Thomas Broyer, Tyler Close, Bil Corry, corvid, Lisa
Dusseault, Roy T. Fielding, Blake Frantz, Anne van Kesteren, Eran Dusseault, Roy T. Fielding, Blake Frantz, Anne van Kesteren, Eran
Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim Hoffmann, Georg Hammer-Lahav, Jeff Hodges, Bjoern Hoehrmann, Achim Hoffmann, Georg
Koppen, Dean McNamee, Mark Miller, Mark Pauley, Yngve N. Pettersen, Koppen, Dean McNamee, Mark Miller, Mark Pauley, Yngve N. Pettersen,
 End of changes. 14 change blocks. 
72 lines changed or deleted 94 lines changed or added

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