draft-ietf-httpstate-cookie-14.txt   draft-ietf-httpstate-cookie-15.txt 
httpstate A. Barth httpstate A. Barth
Internet-Draft U.C. Berkeley Internet-Draft U.C. Berkeley
Obsoletes: 2109 (if approved) September 30, 2010 Obsoletes: 2109 (if approved) October 10, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: April 3, 2011 Expires: April 13, 2011
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpstate-cookie-14 draft-ietf-httpstate-cookie-15
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.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
If you have suggestions for improving this document, please send If you have suggestions for improving this document, please send
email to <mailto:http-state@ietf.org>. Suggestions with test cases email to <mailto:http-state@ietf.org>. Suggestions with test cases
are especially appreciated. Further Working Group information is are especially appreciated. Further Working Group information is
available from <https://tools.ietf.org/wg/httpstate/>. available from <https://tools.ietf.org/wg/httpstate/>.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on April 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 3, 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
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 BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
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
skipping to change at page 16, line 46 skipping to change at page 16, line 46
"may" / "jun" / "jul" / "aug" / "may" / "jun" / "jul" / "aug" /
"sep" / "oct" / "nov" / "dec" ) *OCTET "sep" / "oct" / "nov" / "dec" ) *OCTET
year = 1*4DIGIT ( non-digit *OCTET ) year = 1*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-day-of-month flag is not set and the date-token 1. If the found-time flag is not set and the token matches the
time production, set the found-time flag and set the hour-
value, minute-value, and second-value to the numbers denoted
by the digits in the date-token, respectively. Skip the
remaining sub-steps and continue to the next date-token.
2. If the found-day-of-month flag is not set and 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.
2. 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.
3. 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.
4. If the found-time flag is not set and the token matches the
time production, set the found-time flag and set the hour-
value, minute-value, and second-value to the numbers denoted
by the digits in the date-token, respectively. Skip the
remaining sub-steps and continue to the next date-token.
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 legacy user agents interpret two-digit years 1. NOTE: Some legacy 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
skipping to change at page 36, 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 registry (see [RFC3864]) should be The permanent message header field registry (see [RFC3864]) should be
updated with the following registrations: 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
skipping to change at page 39, line 16 skipping to change at page 39, line 16
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,
Julian Reschke, Peter Saint-Andre, Mark Seaborn, Maciej Stachowiak, Julian Reschke, Peter Saint-Andre, Mark Seaborn, Maciej Stachowiak,
Daniel Stenberg, David Wagner, Dan Winship, and Dan Witte for their Daniel Stenberg, Tatsuhiro Tsujikawa, David Wagner, Dan Winship, and
valuable feedback on this document. Dan Witte for their valuable feedback on this document.
Author's Address Author's Address
Adam Barth Adam Barth
University of California, Berkeley University of California, Berkeley
Email: abarth@eecs.berkeley.edu Email: abarth@eecs.berkeley.edu
URI: http://www.adambarth.com/ URI: http://www.adambarth.com/
 End of changes. 13 change blocks. 
27 lines changed or deleted 21 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/