Re: [http-state] draft-ietf-httpstate-cookie-05 posted

"Paul E. Jones" <paulej@packetizer.com> Mon, 15 March 2010 23:22 UTC

Return-Path: <paulej@packetizer.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 1E8DB3A6800 for <http-state@core3.amsl.com>; Mon, 15 Mar 2010 16:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.274
X-Spam-Level:
X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599]
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 FgFcXQiv9u7g for <http-state@core3.amsl.com>; Mon, 15 Mar 2010 16:22:24 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id D12F93A6862 for <http-state@ietf.org>; Mon, 15 Mar 2010 16:21:08 -0700 (PDT)
Received: from berlin.arid.us (rrcs-98-101-146-183.midsouth.biz.rr.com [98.101.146.183]) (authenticated bits=0) by dublin.packetizer.com (8.14.2/8.14.2) with ESMTP id o2FNL2wT012331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Mar 2010 19:21:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1268695267; bh=MF4SWBS2mIzLIg3qdltGhyxnqAAWY8vM6R7qtDdqzTU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=p30YDLP164iaK6YXJWKwe8dXxp1Och+/Ar99F//upmcCXAjI1J2EL76S7zUaWTvtB Co9BYr0XytPIwon/QIwkN4giahdZVGx++5qIYIlT2eIJ4Nulpc+MV8qNgH082D/9WM Jai1ecQq/Zj6H9Zj91HcB0uDv3YZRXFQFMenE1S8=
Received: from sydney (sydney.arid.us [192.168.1.20]) (authenticated bits=0) by berlin.arid.us (8.14.2/8.14.2) with ESMTP id o2FNL0h8016382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Mar 2010 19:21:00 -0400
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Daniel Stenberg'" <daniel@haxx.se>
References: <5c4444771003071050r3475798co95cc192d1f2e8190@mail.gmail.com> <op.u9dpzpdoqrq7tp@acorna> <5c4444771003101823u25842652o33b49b2be81f4cfc@mail.gmail.com> <alpine.DEB.2.00.1003112201360.25452@tvnag.unkk.fr> <op.u9feulgkqrq7tp@acorna> <009401cac476$eb8c83c0$c2a58b40$@com> <5c4444771003151240h61a87c3fp9a1649d1163111ce@mail.gmail.com> <009a01cac489$47f0fda0$d7d2f8e0$@com> <alpine.DEB.2.00.1003152251531.27391@tvnag.unkk.fr>
In-Reply-To: <alpine.DEB.2.00.1003152251531.27391@tvnag.unkk.fr>
Date: Mon, 15 Mar 2010 19:20:59 -0400
Message-ID: <00a601cac496$2be978a0$83bc69e0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Content-language: en-us
Thread-index: AcrEiigNu686qSX6Si2G6ON2LXXosQACqJfQ
Cc: 'http-state' <http-state@ietf.org>
Subject: Re: [http-state] draft-ietf-httpstate-cookie-05 posted
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: Mon, 15 Mar 2010 23:22:26 -0000

Daniel,

> > Also consider that it's not the web server that will generate
> cookies, but
> > many thousands of application developers will create cookies and
> specify
> > expiration dates.  There are just a handful of browser vendors.
> 
> Ehum.
> 
> We're taking HTTP cookies here: they are implemented and used client-
> side by
> way more implementations than "a handful of browser vendors".
> 
> I'm not saying that changes the argument, I just want things right.

Some cookies might be created client-side in JavaScript, for example, but
the particular text we're referring to in the security section talks about
cookies generated by the server.

My point is that thousands of application developers using a wide variety of
tools (perl, python, Ruby, PHP, etc.) generate cookies.  This is not really
the "server", but the server application. While that might be a minor nit,
my primary point was that there are loads of developers generating cookies
server-side, but there are only a small handful of browsers that need to
handle those cookies.  Further, the browsers *must* be able to do something
intelligent with a cookie that is syntactically correct and has a year that
is beyond 2038.

Thus, I think the requirement (or recommendation, actually) for proper
treatment should be on the client (browser), not the server or server
application.  What would be the justification for a browser to not provide
reasonable treatment of a cookie set to expire in 2050?

Paul