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

Adam Barth <ietf@adambarth.com> Wed, 03 February 2010 03:59 UTC

Return-Path: <adam@adambarth.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9CE63A68C9 for <http-state@core3.amsl.com>; Tue, 2 Feb 2010 19:59:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level:
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhTze7wuYBFf for <http-state@core3.amsl.com>; Tue, 2 Feb 2010 19:59:05 -0800 (PST)
Received: from mail-pz0-f179.google.com (mail-pz0-f179.google.com [209.85.222.179]) by core3.amsl.com (Postfix) with ESMTP id 289D73A6814 for <http-state@ietf.org>; Tue, 2 Feb 2010 19:59:05 -0800 (PST)
Received: by pzk9 with SMTP id 9so930879pzk.31 for <http-state@ietf.org>; Tue, 02 Feb 2010 19:59:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.7.30 with SMTP id 30mr461247wfg.321.1265169583133; Tue, 02 Feb 2010 19:59:43 -0800 (PST)
From: Adam Barth <ietf@adambarth.com>
Date: Tue, 2 Feb 2010 19:58:07 -0800
Message-ID: <7789133a1002021958g49bad0c4s4472ecb046f28c5e@mail.gmail.com>
To: Dan Winship <dan.winship@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: http-state@ietf.org
Subject: [http-state] A non-string cookie API (was: non-ASCII cookie values)
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Wed, 03 Feb 2010 03:59:05 -0000

On Tue, Feb 2, 2010 at 6:21 PM, Dan Winship <dan.winship@gmail.com> wrote:
> One of the major reasons cookies are such a disaster is that web site
> frameworks and document.cookie both expose cookies to web site authors
> as just strings, and expect the web site authors to get all the nasty
> syntax details correct. Which they of course don't.
>
> Although in the short term we need to nail down exactly how
> document.cookie works for backward-compatibility purposes, in the long
> run, we might be able to make the world a better place if we helped
> design a fabulous new higher-level cookie API for HTML5, where the
> browser would handle the tricky syntax bits, and would just throw an
> exception if the page tried to use an illegal cookie name, etc. This new
> API could even fix some issues that we aren't currently able to fix in
> the spec, eg, by setting the "Secure" flag on the cookie by default if
> the page had been loaded over https, etc.

That's a good point.  I'll refactor the interface to the storage model
so that it can be manipulated directly by other specs without having
to serialize their requests to a set-cookie-string.

> (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.

Adam