[http-state] [Technical Errata Reported] RFC6265 (3931)
RFC Errata System <rfc-editor@rfc-editor.org> Mon, 24 March 2014 07:23 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: http-state@ietfa.amsl.com
Delivered-To: http-state@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00CE1A011C for <http-state@ietfa.amsl.com>; Mon, 24 Mar 2014 00:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0A02jakpu0W for <http-state@ietfa.amsl.com>; Mon, 24 Mar 2014 00:23:04 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 882EC1A010E for <http-state@ietf.org>; Mon, 24 Mar 2014 00:23:04 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id ECB2E7FC393; Mon, 24 Mar 2014 00:23:03 -0700 (PDT)
To: abarth@eecs.berkeley.edu, barryleiba@computer.org, presnick@qti.qualcomm.com, Jeff.Hodges@kingsmountain.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20140324072303.ECB2E7FC393@rfc-editor.org>
Date: Mon, 24 Mar 2014 00:23:03 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/http-state/Z-VnZIpncYY61Ynm9nGOnizbpcs
Cc: rfc-editor@rfc-editor.org, joker.vd@gmail.com, http-state@ietf.org
Subject: [http-state] [Technical Errata Reported] RFC6265 (3931)
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state/>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Mar 2014 07:23:07 -0000
The following errata report has been submitted 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 -------------------------------------- Type: Technical Reported by: Semyon Kholodnov <joker.vd@gmail.com> 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. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- 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] [Technical Errata Reported] RFC6265 … RFC Errata System
- Re: [http-state] [Technical Errata Reported] RFC6… Barry Leiba
- Re: [http-state] [Technical Errata Reported] RFC6… Barry Leiba
- [http-state] [Errata Rejected] RFC6265 (3931) RFC Errata System