Re: [http-state] Question regarding RFC 6265 and ietf process

Daniel Stenberg <> Sun, 06 September 2015 18:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7CEE31B2BAB for <>; Sun, 6 Sep 2015 11:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.139
X-Spam-Level: *
X-Spam-Status: No, score=1.139 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5ySMzvGoveeO for <>; Sun, 6 Sep 2015 11:07:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1a28:1200:9::2]) by (Postfix) with ESMTP id CD0491A8989 for <>; Sun, 6 Sep 2015 11:07:22 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.14.4/8.14.4/Debian-7) with ESMTP id t86I7INX018484 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 6 Sep 2015 20:07:18 +0200
Received: from localhost (dast@localhost) by (8.14.4/8.14.4/Submit) with ESMTP id t86I7Hcj018476; Sun, 6 Sep 2015 20:07:17 +0200
X-Authentication-Warning: dast owned process doing -bs
Date: Sun, 6 Sep 2015 20:07:17 +0200 (CEST)
From: Daniel Stenberg <>
To: Fagner Martins <>
In-Reply-To: <>
Message-ID: <>
References: <>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: <>
Cc: HTTP-state mailing list <>
Subject: Re: [http-state] Question regarding RFC 6265 and ietf process
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 06 Sep 2015 18:07:28 -0000

On Tue, 1 Sep 2015, Fagner Martins wrote:

> I am not a veteran on the internet, so I am not aware of how the process 
> works. But would it make sense to amend the RFC to account for characters 
> allowed in the browsers but realistically disallowed by most frameworks due 
> to historical reasons?
> It would be very useful to make the RFC a documentation to serve as a 
> baseline for how the web *and the server-side languages *that are built on 
> it actually work instead of restricting only to how browsers work in the 
> wild.

The work on RFC 6265 was certainly not just to document how browsers work. We 
worked on documenting how cookies are used in general everywhere on the web 
and I can't recall anyone mentioning this restriction during that process.

But also, this restriction seems very arbitrary and random and I don't see how 
any spec in the cookie history has made these frameworks make this decision. 
My personal opinion is that this is an implementation bug, not a problem with 
the spec.