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

Adam Barth <ietf@adambarth.com> Mon, 15 March 2010 22:10 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 31FCC3A69AA for <http-state@core3.amsl.com>; Mon, 15 Mar 2010 15:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.944
X-Spam-Level:
X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 B66SB6bArYyM for <http-state@core3.amsl.com>; Mon, 15 Mar 2010 15:10:38 -0700 (PDT)
Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id E61053A6887 for <http-state@ietf.org>; Mon, 15 Mar 2010 15:10:36 -0700 (PDT)
Received: by gxk9 with SMTP id 9so2141973gxk.8 for <http-state@ietf.org>; Mon, 15 Mar 2010 15:10:41 -0700 (PDT)
Received: by 10.101.189.21 with SMTP id r21mr4863004anp.209.1268691041495; Mon, 15 Mar 2010 15:10:41 -0700 (PDT)
Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx.google.com with ESMTPS id 22sm709532ywh.16.2010.03.15.15.10.40 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Mar 2010 15:10:40 -0700 (PDT)
Received: by yxe1 with SMTP id 1so1808747yxe.31 for <http-state@ietf.org>; Mon, 15 Mar 2010 15:10:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.186.30 with SMTP id n30mr2076375anp.180.1268691040227; Mon, 15 Mar 2010 15:10:40 -0700 (PDT)
In-Reply-To: <009a01cac489$47f0fda0$d7d2f8e0$@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> <009a01cac489$47f0fda0$d7d2f8e0$@com>
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 15 Mar 2010 15:10:20 -0700
Message-ID: <5c4444771003151510n2264a33ct26f627a11b202b16@mail.gmail.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 22:10:42 -0000

On Mon, Mar 15, 2010 at 2:48 PM, Paul E. Jones <paulej@packetizer.com> wrote:
>> 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.

The spec already requires UAs to handle this case.  As I said above,
this language is in the spec as advice to help servers deal with
existing UAs that do not comply with the spec.  By definition, the UAs
we're concerened about here cannot be fixed.

> I'm concerned with inserting language that requires behavior to try to overcome
> issues with user agents.

That's how the web works.

> Do such issues exist in practice?  If so, we ought to fix the browser.

I haven't tested browsers, but I do know of these sorts of issues
occurring in HTTP caching headers, for example in IE6.

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

So?

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

I'm not very interested in the blame game.  The spec requires UAs to
handle these far-future dates in a reasonable way.  The spec also
recommends servers avoid using these dates because of interoperability
issues.  If we find a case where the server is using such a date and
the UA is having trouble processing it, I'd recommend that both the
server and the UA change.

> The UA might want to change the date to 2037 internally and I doubt anybody
> would care.

That is, in effect, what the spec has the UA do.

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

That is required by the current draft.

On Mon, Mar 15, 2010 at 2:57 PM, Daniel Stenberg <daniel@haxx.se> wrote:
> On Mon, 15 Mar 2010, Adam Barth wrote:
>> 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.
>
> Do we actually know of such existing user agents?

I don't have specific knowledge of any such existing user agents.
However, I haven't tried testing for the issue either.

Yngve, was your recommendation motivated by the behavior of any
particular user agent?

Adam