Re: #290: Motivate one-year limit for Expires

Mark Nottingham <mnot@mnot.net> Sat, 28 April 2012 04:25 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1C521F85AD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 27 Apr 2012 21:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KrpnxMNj9Kh for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 27 Apr 2012 21:25:43 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 85B0121F85B1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 27 Apr 2012 21:25:43 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SNzDY-0001qm-CB for ietf-http-wg-dist@listhub.w3.org; Sat, 28 Apr 2012 04:25:08 +0000
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <mnot@mnot.net>) id 1SNzDL-0001oT-NP for ietf-http-wg@listhub.w3.org; Sat, 28 Apr 2012 04:24:55 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1SNzDI-0007IE-8p for ietf-http-wg@w3.org; Sat, 28 Apr 2012 04:24:53 +0000
Received: from mnot-mini.mnot.net (unknown [118.209.44.180]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B436322E1EB; Sat, 28 Apr 2012 00:24:30 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CALcoZir2Vweiu930u4fLpkJAR7qEFjE1Cyb58Qcw-mwqcronqA@mail.gmail.com>
Date: Sat, 28 Apr 2012 14:24:26 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5BFD553C-6398-4B76-8A2C-36037842CF91@mnot.net>
References: <891657B9-2F11-43D6-A9A0-4C6663DAC127@mnot.net> <5635FDB8-10C4-4442-8D2C-B0CC709B55B9@mnot.net> <E26CB1BD-88FB-4A35-A79C-06BC0737DFDE@mnot.net> <CALcoZir2Vweiu930u4fLpkJAR7qEFjE1Cyb58Qcw-mwqcronqA@mail.gmail.com>
To: Mark Baker <distobj@acm.org>
X-Mailer: Apple Mail (2.1257)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1SNzDI-0007IE-8p 635245a6b8619f3289f02c2e77b6f24a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #290: Motivate one-year limit for Expires
Archived-At: <http://www.w3.org/mid/5BFD553C-6398-4B76-8A2C-36037842CF91@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/13493
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1SNzDY-0001qm-CB@frink.w3.org>
Resent-Date: Sat, 28 Apr 2012 04:25:08 +0000

On 28/04/2012, at 2:07 PM, Mark Baker wrote:

> On Thu, Aug 18, 2011 at 12:18 AM, Mark Nottingham <mnot@mnot.net> wrote:
>> Scheduling for -16.
>> 
>> 
>> On 30/07/2011, at 6:47 AM, Mark Nottingham wrote:
>> 
>>> Remove the requirement in p6 3.3 and replace it with:
>>> 
>>> """
>>> Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes are no longer prohibited, extremely large values have been demonstrated to cause problems (e.g., clock overflows due to use of 32-bit integers for time values), and most caches will evict a response far sooner than that. Therefore, senders ought not produce them.
>>> """
> 
> I was reviewing this issue while looking up some information for a
> client, and ran across a sentence that I see didn't receive any
> consideration in last year's discussion. Preceding the "SHOULD NOT
> send Expires dates more than one year in the future" sentence in 2616
> 14.21 is this;
> 
>   To mark a response as "never expires," an origin server sends an
>   Expires date approximately one year from the time the response is
>   sent.
> 
> This says to me that the (approx) one year number has special
> semantics beyond those of a limit. It would seem to indicate that, for
> example, a two year expiry would expire before a one year expiry.
> 
> Is anybody aware of an implementation that treats "one year" as
> special in this way, either explicitly or effectively (e.g. if any
> expiry >= one year was assumed to mean "never expires").


I'm not. My suspicion is that the wording in 2616 was put in with the assumption that no one would ever think of using an expiry further out than a year -- not anticipating the well-intentioned campaigns for "far-future expires" (that cause other problems).

As such, I don't think this is an intentional (or implemented) additional semantic over the obvious semantics of Expires. 

Anyone else know different?



--
Mark Nottingham   http://www.mnot.net/