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

From: Mark Nottingham <[email-masked]>
Date: Sun, 24 Jul 2011 13:46:27 -0400

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/290>

In p6 3.3,

A server SHOULD NOT send Expires dates more than one year in the future.

I did some asking around, and it seems like the idea behind this was that an Expires so far in the future was felt to be more often the sign of bad clocks or administrator error than an intention for such a long TTL (considering that pretty much any eviction algorithm would get rid of it far beforehand).

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

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

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 19:53:03 +0200

Hi Mark,

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

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 ?

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 24 Jul 2011 13:55:11 -0400

> shouldn't we suggest that destinations ignore the large value instead ?

Why should they ignore if they don't have the problem?

Besides which, this would be introducing a requirement that makes several previously conformant implementations non-conformant.

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 20:06:05 +0200

> Why should they ignore if they don't have the problem?

How can they know whether there is a problem ? Let's imagine that my server
is set one year in the future and emits Expires dates one year and a month
away. What I understand is that people were suggesting that more than one
year was a sign of misconfiguration which is the case here. So probably that
ignoring the date is easier to recover from than keeping the object in cache
for that long.

> Besides which, this would be introducing a requirement that makes several previously conformant implementations non-conformant. 

Well, not exactly since in the past it was a SHOULD NOT, so we don't know
how recipients consider larger values (some may already decide to ignore
them or to bound them to 1 year), which is the spirit of your proposal
anyway.

I feel like two distinct issues are being discussed here :
  - how to avoid recipient's wrong behaviour
  - how to deal with an error at the server's

I was dicussing the second point but you appear to be discussing the former
(which I agree with).

Maybe the second point is so marginal that it can safely be ignored ?

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 24 Jul 2011 14:10:18 -0400

> ignoring the date is easier to recover from than keeping the object in cache

I don't understand. 

> them or to bound them to 1 year), which is the spirit of your proposal

No, there is no current requirement in HTTP for caches to impose the one-year limit; this would be a new requirement.

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 20:15:08 +0200

> > ignoring the date is easier to recover from than keeping the object in cache

If my server emits an Expires header with a date in 2013 because of reboot
with a wrong date, some caches might cache the content for a long time. Even
if I fix the date when I notice it, some caches will still have the issue. I'm
not saying this is something critical, I'm saying that I think that's one of
the concerns you quoted when saying that longer TTLs are generaly caused by
clock errors.

> No, there is no current requirement in HTTP for caches to impose the one-year limit; this would be a new requirement.

OK.

Thanks,
Willy

---

From: Brian Pane <[email-masked]>
Date: Sun, 24 Jul 2011 11:16:06 -0700

> 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

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 24 Jul 2011 14:16:40 -0400

> the concerns you quoted when saying that longer TTLs are generaly caused by

True, but the date skew *should* be detected if the age is correctly calculated.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 24 Jul 2011 14:17:53 -0400

> detect the overflow, but maybe not.

Right -- to me, that's a bigger concern, and we might amend the proposed text to note that specifically. I don't know that we can do much else; implementations are just going to have to change how they store and work with time as it approaches...

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 29 Jul 2011 13:47:45 -0700

Updated proposal:

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