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

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

Mark.

Received on Saturday, 28 April 2012 04:08:09 UTC