draft-ietf-httpstate-cookie-17.txt   draft-ietf-httpstate-cookie-18.txt 
httpstate A. Barth httpstate A. Barth
Internet-Draft U.C. Berkeley Internet-Draft U.C. Berkeley
Obsoletes: 2965 (if approved) October 26, 2010 Obsoletes: 2965 (if approved) November 9, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: April 29, 2011 Expires: May 13, 2011
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpstate-cookie-17 draft-ietf-httpstate-cookie-18
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 April 29, 2011. This Internet-Draft will expire on May 13, 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 4, line 11 skipping to change at page 4, line 11
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 34 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 34
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 34 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 34
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 35 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 35
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 35 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 35
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 36 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 37 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . . 39 10.2. Informative References . . . . . . . . . . . . . . . . . . 38
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41
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
skipping to change at page 6, line 9 skipping to change at page 6, line 9
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.
2. Conventions 2. Conventions
2.1. Conformance Criteria 2.1. Conformance Criteria
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
steps") are to be interpreted with the meaning of the key word steps") are to be interpreted with the meaning of the key word
("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm. ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm.
Conformance requirements phrased as algorithms or specific steps can Conformance requirements phrased as algorithms or specific steps can
be implemented in any manner, so long as the end result is be implemented in any manner, so long as the end result is
equivalent. In particular, the algorithms defined in this equivalent. In particular, the algorithms defined in this
specification are intended to be easy to understand and are not specification are intended to be easy to understand and are not
skipping to change at page 12, line 12 skipping to change at page 12, line 12
httponly-av = "HttpOnly" httponly-av = "HttpOnly"
extension-av = <any CHAR except CTLs or ";"> extension-av = <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 Base 16 [RFC3548]. example, using Base 16 [RFC4648].
The portions of the set-cookie-string produced by the cookie-av term The portions of the set-cookie-string produced by the cookie-av term
are known as attributes. To maximize compatibility with user agents, are known as attributes. To maximize compatibility with user agents,
servers SHOULD NOT produce two attributes with the same name in the servers SHOULD NOT produce two attributes with the same name in the
same set-cookie-string. same set-cookie-string.
Servers SHOULD NOT include more than one Set-Cookie header field in Servers SHOULD NOT include more than one Set-Cookie header field in
the same response with the same cookie-name. the same response with the same cookie-name.
If a server sends multiple responses containing Set-Cookie headers If a server sends multiple responses containing Set-Cookie headers
skipping to change at page 18, line 7 skipping to change at page 18, line 7
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 converting the A canonicalized host name is the string generated by the following
host name to a sequence of individual domain name labels, and convert algorithm:
each label that is not a NR-LDH label, to a A-label (see Section
2.3.2.1 of [RFC5890] for the fomer and latter), or to a "punycode 1. Convert the host name to a sequence of individual domain name
label" (a label resulting from the "ToASCII" conversion in Section 4 labels.
of [RFC3490]), as appropriate (see Section 6.3 of this
specification). 2. Convert each label that is not a NR-LDH label, to a A-label (see
Section 2.3.2.1 of [RFC5890] for the fomer and latter), or to a
"punycode label" (a label resulting from the "ToASCII" conversion
in Section 4 of [RFC3490]), as appropriate (see Section 6.3 of
this specification).
3. Concatentate the resulting labels, separated by a %x2E (".")
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. o The domain string and the string are identical.
o All of the following conditions hold: o All of the following conditions hold:
skipping to change at page 26, line 19 skipping to change at page 26, line 19
12. Insert the newly created cookie into the cookie store. 12. Insert the newly created cookie into the cookie store.
A cookie is "expired" if the cookie has an expiry date in the past. 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 implementaiton 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.
skipping to change at page 29, line 52 skipping to change at page 29, line 52
serialized date string. serialized date string.
6.3. IDNA dependency and migration 6.3. IDNA dependency and migration
IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490]. However, there are IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490]. However, there are
differences between the two specifications, and thus there can be differences between the two specifications, and thus there can be
differences in processing (e.g. converting) domain name labels that differences in processing (e.g. converting) domain name labels that
have been registered under one from those registered under the other. have been registered under one from those registered under the other.
There will be a transition period of some time during which IDNA2003- There will be a transition period of some time during which IDNA2003-
based domain name labels will exist in the wild. User agents SHOULD based domain name labels will exist in the wild. User agents SHOULD
implement IDNA2008 [RFC5890] and MAY implement [Unicode Technical implement IDNA2008 [RFC5890] and MAY implement [UTS46] or [RFC5895]
Standard #46 (UTS46) <http://unicode.org/reports/tr46/>] or [RFC5895]
in order to facilitate their IDNA transition. If a user agent does in order to facilitate their IDNA transition. If a user agent does
not implement IDNA2008, the user agent MUST implement IDNA2003 not implement IDNA2008, the user agent MUST implement IDNA2003
[RFC3490]. [RFC3490].
7. Privacy Considerations 7. Privacy Considerations
Cookies are often criticized for letting servers track users. For Cookies are often criticized for letting servers track users. For
example, a number of "web analytics" companies use cookies to example, a number of "web analytics" companies use cookies to
recognize when a user returns to a web site or visits another web recognize when a user returns to a web site or visits another web
site. Although cookies are not the only mechanism servers can use to site. Although cookies are not the only mechanism servers can use to
skipping to change at page 38, line 46 skipping to change at page 38, line 46
[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, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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, August 2010. RFC 5890, August 2010.
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for
Internationalized Domain Names in Applications (IDNA)
2008", RFC 5895, September 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010.
10.2. Informative References 10.2. Informative References
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997. Mechanism", RFC 2109, February 1997.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000. Mechanism", RFC 2965, October 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[Netscape] [Netscape]
Netscape Communications Corp., "Persistent Client State -- Netscape Communications Corp., "Persistent Client State --
HTTP Cookies", 1999, <http://web.archive.org/web/ HTTP Cookies", 1999, <http://web.archive.org/web/
20020803110822/http://wp.netscape.com/newsref/std/ 20020803110822/http://wp.netscape.com/newsref/std/
cookie_spec.html>. cookie_spec.html>.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology Vol. 1, Politics", ACM Transactions on Internet Technology Vol. 1,
#2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>. #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003. Encodings", RFC 4648, October 2006.
[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,
September 2004. September 2004.
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for
Internationalized Domain Names in Applications (IDNA)
2008", RFC 5895, September 2010.
[UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility
Processing", Unicode Technical Standards # 46, 2010,
<http://unicode.org/reports/tr46/>.
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. 13 change blocks. 
28 lines changed or deleted 35 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/