[http-state] [Technical Errata Reported] RFC6265 (3663)

RFC Errata System <rfc-editor@rfc-editor.org> Tue, 18 June 2013 00:30 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DCC21F8F7B for <http-state@ietfa.amsl.com>; Mon, 17 Jun 2013 17:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.473
X-Spam-Level:
X-Spam-Status: No, score=-103.473 tagged_above=-999 required=5 tests=[AWL=1.127, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDtnm7LcyXUa for <http-state@ietfa.amsl.com>; Mon, 17 Jun 2013 17:30:48 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 02B3221F8F09 for <http-state@ietf.org>; Mon, 17 Jun 2013 17:30:43 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 7DF236211A; Mon, 17 Jun 2013 17:28:30 -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: <20130618002830.7DF236211A@rfc-editor.org>
Date: Mon, 17 Jun 2013 17:28:30 -0700 (PDT)
Cc: rfc-editor@rfc-editor.org, dthaler@microsoft.com, http-state@ietf.org
Subject: [http-state] [Technical Errata Reported] RFC6265 (3663)
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 18 Jun 2013 00:30:49 -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=3663

--------------------------------------
Type: Technical
Reported by: Dave Thaler <dthaler@microsoft.com>;

Section: 2.2

Original Text
-------------
The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet),

Corrected Text
--------------
The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F), LF (line feed), NUL (null octet),

Notes
-----
HEXDIG is defined in [RFC5234], Appendix B.1 as
  HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
Note that lower case a-f are not legal.

That leaves two possible meanings: (1) that HEXDIG is correct and the text in 2.2 is wrong in suggesting a-f are legal, or (2) that a-f are legal and that a different definition of HEXDIG was intended than the one referenced.

This ambiguity is resolved in RFC 6265 section 5.1.4 which says:
"   A request-path path-matches a given cookie-path if at least one of
   the following conditions holds:

   o  The cookie-path and the request-path are identical."
This section does no case normalization, nor any case-insensitive comparison of the path.  The path is case sensitive and the comparison is for "identical".
Thus, the hex letters in HEXDIG must be case sensitive, and thus the only interpretation of HEXDIG that is consistent with this test for "identical" is the one that does not allow both upper-case and lower-case.

For comparison, RFC 3986 (and its predecessor RFC 2234) also have the same restriction of HEXDIG only supporting upper case, although RFC 3986 contains the additional explanation:
"      pct-encoded = "%" HEXDIG HEXDIG

   The uppercase hexadecimal digits 'A' through 'F' are equivalent to
   the lowercase digits 'a' through 'f', respectively.  If two URIs
   differ only in the case of hexadecimal digits used in percent-encoded
   octets, they are equivalent.  For consistency, URI producers and
   normalizers should use uppercase hexadecimal digits for all percent-
   encodings."

Although the URI syntax in RFC 3986 disallows lower-case hex digits, the above text nonetheless says that such a string would be "equivalent". This is in contrast to RFC 6265 which requires the match to be "identical", not just "equivalent".

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