[http-state] [Technical Errata Reported] RFC6265 (3765)
RFC Errata System <rfc-editor@rfc-editor.org> Sat, 26 October 2013 07:38 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 7FC7911E816F for <http-state@ietfa.amsl.com>; Sat, 26 Oct 2013 00:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.421
X-Spam-Level:
X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.179, 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 YNNM4oYdU0ST for <http-state@ietfa.amsl.com>; Sat, 26 Oct 2013 00:38:12 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 178DC11E8275 for <http-state@ietf.org>; Sat, 26 Oct 2013 00:37:58 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 37CBE726001; Sat, 26 Oct 2013 00:29:08 -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: <20131026072908.37CBE726001@rfc-editor.org>
Date: Sat, 26 Oct 2013 00:29:08 -0700
Cc: info@firmen.jknaupp.de, rfc-editor@rfc-editor.org, http-state@ietf.org
Subject: [http-state] [Technical Errata Reported] 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 07:38:13 -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=3765 -------------------------------------- Type: Technical Reported by: Johannes Knaupp <info@firmen.jknaupp.de> 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). 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] [Errata Rejected] RFC6265 (3765) RFC Errata System
- [http-state] [Technical Errata Reported] RFC6265 … RFC Errata System
- Re: [http-state] [Technical Errata Reported] RFC6… Julian Reschke
- Re: [http-state] [Technical Errata Reported] RFC6… Barry Leiba
- Re: [http-state] [Technical Errata Reported] RFC6… Daniel Stenberg