[http-state] [Errata Rejected] RFC6265 (3931)

1 view
Skip to first unread message

RFC Errata System

unread,
Mar 24, 2014, 11:16:17 AM3/24/14
to joke...@gmail.com, aba...@eecs.berkeley.edu, rfc-e...@rfc-editor.org, barry...@computer.org, ie...@ietf.org, http-...@ietf.org
The following errata report has been rejected for RFC6265,
"HTTP State Management Mechanism".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6265&eid=3931

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Semyon Kholodnov <joke...@gmail.com>
Date Reported: 2014-03-24
Rejected by: Barry Leiba (IESG)

Section: 5.1.1

Original Text
-------------
The user agent MUST use an algorithm equivalent to the following
algorithm to parse a cookie-date. Note that the various boolean
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.

cookie-date = *delimiter date-token-list *delimiter
date-token-list = date-token *( 1*delimiter date-token )
date-token = 1*non-delimiter

delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
non-digit = %x00-2F / %x3A-FF

day-of-month = 1*2DIGIT ( non-digit *OCTET )
month = ( "jan" / "feb" / "mar" / "apr" /
"may" / "jun" / "jul" / "aug" /
"sep" / "oct" / "nov" / "dec" ) *OCTET
year = 2*4DIGIT ( non-digit *OCTET )
time = hms-time ( non-digit *OCTET )
hms-time = time-field ":" time-field ":" time-field
time-field = 1*2DIGIT

2. Process each date-token sequentially in the order the date-tokens
appear in the cookie-date:

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-
month flag and set the day-of-month-value to the number
denoted by the date-token. Skip the remaining sub-steps and
continue to the next date-token.

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
month-value to the month denoted by the date-token. Skip the
remaining sub-steps and continue to the next date-token.

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
year-value to the number denoted by the date-token. Skip the
remaining sub-steps and continue to the next date-token.

Corrected Text
--------------
The user agent MUST use an algorithm equivalent to the following
algorithm to parse a cookie-date. Note that the various boolean
flags defined as a part of the algorithm (i.e., found-day-of-week,
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.

cookie-date = *delimiter date-token-list *delimiter
date-token-list = date-token *( 1*delimiter date-token )
date-token = 1*non-delimiter

delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
non-digit = %x00-2F / %x3A-FF

day-of-week = weekday / wkday
wkday = "mon" / "tue" / "wed" / "thu" / "fri" / "sat" /
"sun"
weekday = "monday" / "tuesday" / "wednesday" / "thursday" /
"friday" / "saturday" / "sunday"
day-of-month = 1*2DIGIT ( non-digit *OCTET )
month = ( "jan" / "feb" / "mar" / "apr" /
"may" / "jun" / "jul" / "aug" /
"sep" / "oct" / "nov" / "dec" ) *OCTET
year = 2*4DIGIT ( non-digit *OCTET )
time = hms-time ( non-digit *OCTET )
hms-time = time-field ":" time-field ":" time-field
time-field = 1*2DIGIT

2. Process each date-token sequentially in the order the date-tokens
appear in the cookie-date:

1. If the found-day-of-week flag is not set and the token
matches the day-of-week production, set found-day-of-week
flag. Skip the remaining steps and continue to the next
date-token.

2. 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 found-day-of-month flag is not set and the date-token
matches the day-of-month production, set the found-day-of-
month flag and set the day-of-month-value to the number
denoted by the date-token. Skip the remaining sub-steps and
continue to the next date-token.

4. If the found-month flag is not set and the date-token matches
the month production, set the found-month flag and set the
month-value to the month denoted by the date-token. Skip the
remaining sub-steps and continue to the next date-token.

5. If the found-year flag is not set and the date-token matches
the year production, set the found-year flag and set the
year-value to the number denoted by the date-token. Skip the
remaining sub-steps and continue to the next date-token.

Notes
-----
4.1.1 defines "sane-cookie-date" as "rfc1123-date, defined in [RFC2616], Section 3.3.1". However, both RFC1123 and RFC2616 mandate that date starts with day of the week, and indeed, most servers send cookies where Expires starts with day of the week.

In this particular case (Expire field) the day-of-week part of the date is insignificant, and client MAY ignore it.
--VERIFIER NOTES--
The reporter misunderstood the algorithm at first, thinking that it would fail when it couldn't parse the weekday token. In fact, the algorithm actually has the flexibility to ignore tokens it doesn't care about, and to handle tokens in any order. So there's no error here.

--------------------------------------
RFC6265 (draft-ietf-httpstate-cookie-23)
--------------------------------------
Title : HTTP State Management Mechanism
Publication Date : April 2011
Author(s) : A. Barth
Category : PROPOSED STANDARD
Source : HTTP State Management Mechanism
Area : Applications
Stream : IETF
Verifying Party : IESG

_______________________________________________
http-state mailing list
http-...@ietf.org
https://www.ietf.org/mailman/listinfo/http-state
Reply all
Reply to author
Forward
0 new messages