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

On Sun, Jul 24, 2011 at 10:53 AM, Willy Tarreau <w@1wt.eu> wrote:

>> So, I propose we remove the requirement and replace it with something like:
>>
>> """
>> 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), and senders ought not produce them.
>> """
>
> But if more than one year is often the cause of a config error or bad clock,
> shouldn't we suggest that destinations ignore the large value instead ?

I think the problem with ignoring on the client side is that the
clients that would need to ignore large values the most are probably
those least likely to detect the problem.  E.g, if you send this:

    Expires: Fri, 01 Jan 2100 00:00:01 GMT

to a client that uses 32-bit Unix time_t values to hold times, how
will that client interpret it?  The implementation might be able to
detect the overflow, but maybe not.

-Brian

Received on Sunday, 24 July 2011 18:16:33 UTC