Re: Cookie-Attribute request header proposal

Daniel Stenberg <> Sun, 04 September 2016 11:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F74112B0E2 for <>; Sun, 4 Sep 2016 04:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.53
X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7T4N6qy225HK for <>; Sun, 4 Sep 2016 04:11:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF1CB12B046 for <>; Sun, 4 Sep 2016 04:11:29 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bgVFw-0002Lz-27 for; Sun, 04 Sep 2016 11:06:32 +0000
Resent-Date: Sun, 04 Sep 2016 11:06:32 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bgVFk-0002Ko-JS for; Sun, 04 Sep 2016 11:06:20 +0000
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1bgVFi-0000UT-LE; Sun, 04 Sep 2016 11:06:20 +0000
Received: from (localhost.localdomain []) by (8.15.2/8.15.2/Debian-4) with ESMTPS id u84B5sA0029300 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 4 Sep 2016 13:05:54 +0200
Received: from localhost (dast@localhost) by (8.15.2/8.15.2/Submit) with ESMTP id u84B5r7f029294; Sun, 4 Sep 2016 13:05:53 +0200
X-Authentication-Warning: dast owned process doing -bs
Date: Sun, 4 Sep 2016 13:05:53 +0200 (CEST)
From: Daniel Stenberg <>
To: David Eckel <>
cc: HTTP Working Group <>, Yves Lafon <>
In-Reply-To: <>
Message-ID: <>
References: <>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.9
X-W3C-Hub-Spam-Report: AWL=0.761, BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bgVFi-0000UT-LE d75545d673f61cdaf6f28b8eac6f8b12
Subject: Re: Cookie-Attribute request header proposal
Archived-At: <>
X-Mailing-List: <> archive/latest/32375
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Thu, 1 Sep 2016, David Eckel wrote:

> Cookie: analyticsId=1;analyticsId=2;__Cookie-Attribute=Path,Domain
> Cookie-Attribute: 
> Path=/,;Path=/index,;Path=/,

> - Opt-in security means a long road to adoption

It's too long road IMO. It'll make every server implementation having to 
default to non-supporting clients and there will never be 100% compliance so 
this header will significantly complicate the server (and client) 
implementations for a very long time (complete deprecating things on the 
Internet is hard and all that) and yet for any client that wants to avoid that 
setup they'll just not send the header...

This, in an area that has turned out harder to change than most other HTTP 
areas (remember all the funky cookies RFCs that have been attemped through the 
years) since (I suspect) server side cookie implementations are so often 
custom and hand rolled out and are not just half a dozen major implmentations 
you can upgrade to the latest version and be done with it.

So no, I don't see this suggestion as a good road forward.