Re: [http-state] A non-string cookie API (was: non-ASCII cookie values)

Dan Winship <> Wed, 03 February 2010 14:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B7B43A6C1B for <>; Wed, 3 Feb 2010 06:23:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.955
X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jfo5zOtDiCoF for <>; Wed, 3 Feb 2010 06:23:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C01383A689B for <>; Wed, 3 Feb 2010 06:23:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPA id D95C2802AE; Wed, 3 Feb 2010 09:24:23 -0500 (EST)
Message-ID: <>
Date: Wed, 03 Feb 2010 09:24:23 -0500
From: Dan Winship <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0
MIME-Version: 1.0
To: Adam Barth <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Daniel Stenberg <>,
Subject: Re: [http-state] A non-string cookie API (was: non-ASCII cookie values)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Feb 2010 14:23:42 -0000

On 02/02/2010 10:58 PM, Adam Barth wrote:
>> (And likewise, the spec could recommend that web site
>> frameworks/libraries SHOULD provide similar idiot-proof high-level
>> cookie APIs, rather than expecting authors to generate valid Set-Cookie
>> headers by themselves.)
> We can get input from long-time IETF folks, but my understanding is
> that the spec should keep its normative requirements focused on
> protocol messages.

OK, maybe s/SHOULD/should/ then, but see below too.

On 02/03/2010 02:42 AM, Daniel Stenberg wrote:
> Don't we pretty much assume and wish for this for every spec and
> protocol? I mean, we make a smaller set of libraries and frameworks for
> everything that then a large amount of users can use.
> It is really the job of this spec to spell it out?

It's advice based on past implementation experience. We know that lots
of web site authors are going to generate invalid Set-Cookie headers if
their APIs let them. So we should encourage framework authors to provide
better APIs, because that means there will be more valid protocol
messages going over the wire and fewer invalid ones.

-- Dan