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

[Willy Tarreau <[e-mail]>]

On Sun, Jul 24, 2011 at 01:55:11PM -0400, Mark Nottingham wrote:
> 
> On 24/07/2011, at 1:53 PM, Willy Tarreau wrote:
> 
> > Hi Mark,
> > 
> > On Sun, Jul 24, 2011 at 01:46:27PM -0400, Mark Nottingham wrote:
> >> <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.
> >> """
> > 
> > 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 ?
> 
> 
> 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