Re: [http-state] consensus call: cookie server conformance

Adam Barth <ietf@adambarth.com> Sat, 29 January 2011 22:42 UTC

Return-Path: <ietf@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 C2E953A68BC for <http-state@core3.amsl.com>; Sat, 29 Jan 2011 14:42:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.712
X-Spam-Level:
X-Spam-Status: No, score=-4.712 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
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 p4KLwW+UKDoM for <http-state@core3.amsl.com>; Sat, 29 Jan 2011 14:42:13 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id D65903A68BB for <http-state@ietf.org>; Sat, 29 Jan 2011 14:42:12 -0800 (PST)
Received: by gxk27 with SMTP id 27so1770871gxk.31 for <http-state@ietf.org>; Sat, 29 Jan 2011 14:45:22 -0800 (PST)
Received: by 10.236.105.226 with SMTP id k62mr708540yhg.53.1296341122592; Sat, 29 Jan 2011 14:45:22 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id 26sm3527559yhl.23.2011.01.29.14.45.20 (version=SSLv3 cipher=RC4-MD5); Sat, 29 Jan 2011 14:45:21 -0800 (PST)
Received: by iyi42 with SMTP id 42so4061522iyi.31 for <http-state@ietf.org>; Sat, 29 Jan 2011 14:45:19 -0800 (PST)
Received: by 10.231.11.139 with SMTP id t11mr4570027ibt.189.1296341119728; Sat, 29 Jan 2011 14:45:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.35.13 with HTTP; Sat, 29 Jan 2011 14:44:47 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1101292242340.1561@tvnag.unkk.fr>
References: <4D41FA83.5040302@KingsMountain.com> <4D433C9A.7010203@gmail.com> <alpine.DEB.2.00.1101291735580.10943@tvnag.unkk.fr> <AANLkTin1kyVmqAObQAMobf8d97jQjqtP7Ldsh_=s0OTL@mail.gmail.com> <alpine.DEB.2.00.1101292242340.1561@tvnag.unkk.fr>
From: Adam Barth <ietf@adambarth.com>
Date: Sat, 29 Jan 2011 14:44:47 -0800
Message-ID: <AANLkTikxq2HFstovE9ENjXgv0CxXHsuDX2Tr95wKfNEJ@mail.gmail.com>
To: Daniel Stenberg <daniel@haxx.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: IETF HTTP State WG <http-state@ietf.org>
Subject: Re: [http-state] consensus call: cookie server conformance
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: Sat, 29 Jan 2011 22:42:13 -0000

On Sat, Jan 29, 2011 at 2:13 PM, Daniel Stenberg <daniel@haxx.se>; wrote:
> On Sat, 29 Jan 2011, Adam Barth wrote:
>>> I hadn't really considered these details about 'token' there and I agree
>>> that it seems a bit too strict.
>>
>> That rule comes from RFC 2109 (with the bogus parts of the RFC 2109
>> cookie-value syntax removed).  It's certainly stricter than we need.
>> Something like allowing base64 sounds reasonable to me.
>
> As a little comparison, my parser (that seems to work with a vast majority
> of all sites) simply allows anything except ; and = in a cookie name, and
> everything except ; and \r and \n in cookie contents.
>
> Of course that doesn't really say that servers will use all those letters,
> only that a receiving end really has little reason to make it more strict
> than this.

I'd have to check the details, but I suspect that agrees with the user
agent requirements for the current draft, although there might be some
subtitles w.r.t. whitespace handling.

That said, I wouldn't recommend that servers make use of that full
flexibility.  For example, sending unpaired UTF-16 surrogates,
malformed UTF-8 sequences, or null characters is probably not a good
idea.

The question boils down what's sensible for servers to send.  IMHO,
token + base64 is reasonable, but I don't feel that strongly about it.

Adam