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

RFC Errata System <rfc-editor@rfc-editor.org> Sat, 26 October 2013 14:49 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 2DE0521F9F86; Sat, 26 Oct 2013 07:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.425
X-Spam-Level:
X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, 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 I4XbKbnB3IkC; Sat, 26 Oct 2013 07:49:02 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC8611E815E; Sat, 26 Oct 2013 07:49:02 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 7180D726001; Sat, 26 Oct 2013 07:40:14 -0700 (PDT)
To: info@firmen.jknaupp.de, abarth@eecs.berkeley.edu
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20131026144014.7180D726001@rfc-editor.org>
Date: Sat, 26 Oct 2013 07:40:14 -0700 (PDT)
Cc: rfc-editor@rfc-editor.org, barryleiba@computer.org, iesg@ietf.org, http-state@ietf.org
Subject: [http-state] [Errata Rejected] RFC6265 (3765)
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: Sat, 26 Oct 2013 14:49:03 -0000

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=3765

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

Reported by: Johannes Knaupp <info@firmen.jknaupp.de>;
Date Reported: 2013-10-25
Rejected by: Barry Leiba (IESG)

Section: 4.1.1

Original Text
-------------
Servers SHOULD NOT include more than one Set-Cookie header field in
the same response with the same cookie-name.  (See Section 5.2 for
how user agents handle this case.)



Corrected Text
--------------
Servers MUST NOT include more than one Set-Cookie header field in
the same response.

Notes
-----
The HTTP specification (RFC 2616) says in its section 4.2: "Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. [...]"

Since the mentioned condition is not fulfilled in the case of Set-Cookie headers, only one Set-Cookie header is permissible in an HTTP message.

This also applies to the third example in section 3.1, even though it is not clearly specified there whether or not the two Set-Cookies originate from the same server response.

On the internet many HTTP messages contain multiple Set-Cookie headers, and this seems to make sense in order to avoid additional roundtrips. This, however, (1) does not match the HTTP specification, see above, and therefore (2) cannot be used with implementations stating that they were HTTP compatible and consequently only allow a single Set-Cookie header per response. Clearly, this is not a defect of those implementations, but of the specifications which are at least mistakable (if not contradictory).
 --VERIFIER NOTES-- 
Part of the point of RFC 6265 is to document how cookies are actually
used on the Internet.  As is noted in the introduction, existing use
doesn't always conform to what it should.  In particular, we know that
RFC 6265 doesn't always match up with RFC 2616, because the actual usage
isn't always strictly correct.

The variation from RFC 2616 that this report notes is intentional,
documenting the existing usage, and this errata report is rejected.

--------------------------------------
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