IETF Logo Mail Archive

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

Daniel Stenberg <daniel@haxx.se> Sun, 06 September 2015 18:07 UTC

Return-Path: <daniel@haxx.se>
X-Original-To: http-state@ietfa.amsl.com
Delivered-To: http-state@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEE31B2BAB for <http-state@ietfa.amsl.com>; Sun, 6 Sep 2015 11:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ySMzvGoveeO for <http-state@ietfa.amsl.com>; Sun, 6 Sep 2015 11:07:24 -0700 (PDT)
Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id CD0491A8989 for <http-state@ietf.org>; Sun, 6 Sep 2015 11:07:22 -0700 (PDT)
Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (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 giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id t86I7Hcj018476; Sun, 6 Sep 2015 20:07:17 +0200
X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs
Date: Sun, 06 Sep 2015 20:07:17 +0200
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@giant.haxx.se
To: Fagner Martins <eu@fagnermartins.com>
In-Reply-To: <CAK5xtXOF0FG1roQNfzEUtj9x2aNhfG3_O7Sxk_4mGqU1rfD_Mg@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1509062003000.7592@tvnag.unkk.fr>
References: <CAK5xtXOF0FG1roQNfzEUtj9x2aNhfG3_O7Sxk_4mGqU1rfD_Mg@mail.gmail.com>
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: <http://mailarchive.ietf.org/arch/msg/http-state/32nlQ1tDe1GaanGqGekO2sd4MF0>
Cc: HTTP-state mailing list <http-state@ietf.org>
Subject: Re: [http-state] Question regarding RFC 6265 and ietf process
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: 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.

-- 

  / daniel.haxx.se

v2.23.0 | Report a Bug | By Email