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

"Paul E. Jones" <paulej@packetizer.com> Mon, 15 March 2010 21:48 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 880223A6BD5 for <http-state@core3.amsl.com>; Mon, 15 Mar 2010 14:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Level:
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 3aVNT-uvffZJ for <http-state@core3.amsl.com>; Mon, 15 Mar 2010 14:48:53 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id 2E4443A6973 for <http-state@ietf.org>; Mon, 15 Mar 2010 14:48:53 -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 o2FLmjsB004585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Mar 2010 17:48:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1268689730; bh=VdUydhUbQ6PGB6zHDPw7vwPLC4dKkw08x1C/Wof2vtc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=se/CddSKt6evVt8wo8X7l5NJaYHEqg7HiKUxFP9zejC8QAjWheFBf/n4V9G0BCd27 dDSB4mWwp8D4SEeP4pV1DOAMXPkCCHfjWeM6P569T/q9x4RHvtQ6R14IgxIvp2BPSW DPvg5MLnonKoioFDa1se04TNf1vs4z0vhm9mfZqY=
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 o2FLmiSZ016189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Mar 2010 17:48:44 -0400
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Adam Barth'" <ietf@adambarth.com>
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>
In-Reply-To: <5c4444771003151240h61a87c3fp9a1649d1163111ce@mail.gmail.com>
Date: Mon, 15 Mar 2010 17:48:42 -0400
Message-ID: <009a01cac489$47f0fda0$d7d2f8e0$@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: AcrEhPpy/8nY6Nb+TQqVXmoNCwNqWQAAYBmA
Cc: 'Daniel Stenberg' <daniel@haxx.se>, '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 21:48:54 -0000

Adam,

> User agents are required to handle these cases gracefully.  The
> language we're considering is a recommendation for servers to improve
> interoperability with some existing user agents that don't handle this
> case gracefully.

If a UA today would do something strange, the UA needs to be fixed.  I'm
concerned with inserting language that requires behavior to try to overcome
issues with user agents.  Do such issues exist in practice?  If so, we ought
to fix the browser.

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.

When one of these thousands of app developers passes an expiration date of
2050 over the wire and a browser breaks, do we blame the application
developer who composed a proper date or the browser vendor who didn't give
the date reasonable treatment? This language suggests we blame the app
developer, but I don't think that's where blame should be placed.

The UA might want to change the date to 2037 internally and I doubt anybody
would care.  I don't even think that's something noteworthy since the UA
will not likely be around by then.  What is important is that the UAs at
least give reasonable treatment of dates beyond 2038.

Paul