Possible ambiguity in RFC 6265bis
Mark Thomas <markt@apache.org> Tue, 30 July 2024 12:43 UTC
Received: by ietfa.amsl.com (Postfix) id 4CB67C14F604; Tue, 30 Jul 2024 05:43:28 -0700 (PDT)
Delivered-To: ietfarch-httpbisa-archive-bis2juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF18C14F5EC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 30 Jul 2024 05:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.761
X-Spam-Level:
X-Spam-Status: No, score=-2.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=w3.org header.b="e8S01Rct"; dkim=pass (2048-bit key) header.d=w3.org header.b="qYsbGXUo"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lPUU1vjaKS6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 30 Jul 2024 05:43:27 -0700 (PDT)
Received: from mab.w3.org (mab.w3.org [IPv6:2600:1f18:7d7a:2700:d091:4b25:8566:8113]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA5AC14F603 for <httpbisa-archive-bis2Juki@ietf.org>; Tue, 30 Jul 2024 05:43:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:Content-Type:From:To:MIME-Version:Date:Message-ID:Cc:Reply-To :In-Reply-To:References; bh=thzEBO8l+HtRW7Eiygwtf3fIY2Jl4PcBRSeKUdzrFl8=; b=e 8S01Rctv9DhCMVVuHRgRN7AG5wRlv1NRifiPrIrbTEk6tfpU1xTujAU1VO+U0mTDMQnC2TK6uf7Lg r5qo4hb93BveGOEUD+fhHnSyFES0EqrqMA33mkw1lHmXJaclXRnXde/XEkpyO/5ZpGoV9gw/sJn2j DaAXL3kPgDxzR+HE7JeAJmJ3Rdhv3Eh2z22rEmoWtaKnRDDqPqcwqRkK3PvEezcn/0WacTtwOg4L3 XQEjqYCQidYCqevlvzkCs+iacvAMOLvioIE6497FKwpcb6qXYM2GWARC+5kV23VvR+pjV+R2AoAhx q6nQ62uAlSJXvf+L+KfcvWe/dnyM0Ih5Q==;
Received: from lists by mab.w3.org with local (Exim 4.96) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1sYmBH-000eRP-0Q for ietf-http-wg-dist@listhub.w3.org; Tue, 30 Jul 2024 12:42:19 +0000
Resent-Date: Tue, 30 Jul 2024 12:42:19 +0000
Resent-Message-Id: <E1sYmBH-000eRP-0Q@mab.w3.org>
Received: from ip-10-0-0-224.ec2.internal ([10.0.0.224] helo=puck.w3.org) by mab.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <markt@apache.org>) id 1sYmBE-000eQc-1s for ietf-http-wg@listhub.w3.internal; Tue, 30 Jul 2024 12:42:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Content-Type:Subject:From:To:MIME-Version:Date:Message-ID:Cc:Reply-To :In-Reply-To:References; bh=thzEBO8l+HtRW7Eiygwtf3fIY2Jl4PcBRSeKUdzrFl8=; t=1722343336; x=1723207336; b=qYsbGXUoisixuZSid6ZHp7xYzWmiS87IFM9vNbQALjsYwsZ 1GLs468vxTbn5v8h7KBxjCtV5q9hinIAAJ8Aj6g6ltkoukMhcNSJmxc2LlZd+PpuB7z/lmENH3Syt qDRC+XHjXvKkK2pMGzItWvZ8rw/JHuxgf+ku2xyTGm2AmAFj9wNZP7tJBtDSMJLdl7D3HhR/J7O2S cFEKkMah/C1/SdqVJ9q+bO7HlySqfTqSOpmuwlTxzy/Af+/HVA33Mot+kw6DgEE8Sp9HGmfXGyFS0 R23bt+11oygkPBZmNJ/vYtAYv9CQ+ir2OlNag2jA2V6OoyAWIZglppLp2VISgMAg==;
Received-SPF: pass (puck.w3.org: domain of apache.org designates 3.227.148.255 as permitted sender) client-ip=3.227.148.255; envelope-from=markt@apache.org; helo=mxout1-ec2-va.apache.org;
Received: from mxout1-ec2-va.apache.org ([3.227.148.255]) by puck.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <markt@apache.org>) id 1sYmBE-0069RP-0E for ietf-http-wg@w3.org; Tue, 30 Jul 2024 12:42:16 +0000
Received: from mail.apache.org (mailgw-he-de.apache.org [116.203.246.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mxout1-ec2-va.apache.org (ASF Mail Server at mxout1-ec2-va.apache.org) with ESMTPS id 9D9DF4F21D for <ietf-http-wg@w3.org>; Tue, 30 Jul 2024 12:42:12 +0000 (UTC)
Received: (qmail 876134 invoked by uid 116); 30 Jul 2024 12:42:11 -0000
Received: from mailrelay1-he-de.apache.org (HELO mailrelay1-he-de.apache.org) (116.203.21.61) by apache.org (qpsmtpd/0.94) with ESMTP; Tue, 30 Jul 2024 12:42:11 +0000
Authentication-Results: apache.org; auth=none
Received: from [192.168.23.12] (host109-148-116-113.range109-148.btcentralplus.com [109.148.116.113]) by mailrelay1-he-de.apache.org (ASF Mail Server at mailrelay1-he-de.apache.org) with ESMTPSA id 5D9EA40508 for <ietf-http-wg@w3.org>; Tue, 30 Jul 2024 12:42:11 +0000 (UTC)
Message-ID: <2842b8da-90db-4e4a-97f6-837f3aa023c0@apache.org>
Date: Tue, 30 Jul 2024 13:42:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: ietf-http-wg@w3.org
From: Mark Thomas <markt@apache.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-W3C-Hub-Spam-Status: No, score=-11.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DMARC_MISSING=0.001, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: puck.w3.org 1sYmBE-0069RP-0E 083534f37e402044eb902d4ccd97ddda
X-Original-To: ietf-http-wg@w3.org
Subject: Possible ambiguity in RFC 6265bis
Archived-At: <https://www.w3.org/mid/2842b8da-90db-4e4a-97f6-837f3aa023c0@apache.org>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/52164
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/email/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Hi all, I've been looking at the changes in RFC 6265 for possible impact on the Jakarta Servlet specification and the associated implementations (primarily Apache Tomcat). The change of the definition of cookie-name from token to 1*cookie-octet means that it is now possible to have an '=' (equals) character in a cookie name. This has the potential to cause issues as a cookie set with a name of "a=b" and a value of "c" will be interpreted by the user agent as having a name of "a" and a value of "b=c". I did check the archives but couldn't find this specific issue being discussed anywhere. If I missed it I apologise and would appreciate a reference to the discussion. If I haven't missed a previous discussion, I assume the correct thing to do would be to raise an issue in GitHub. Is that correct? Thanks, Mark
- Possible ambiguity in RFC 6265bis Mark Thomas
- Re: Possible ambiguity in RFC 6265bis Daniel Stenberg