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

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/

Received on Saturday, 28 April 2012 04:24:55 UTC