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

[Willy Tarreau <[e-mail]>]

On Sun, Jul 24, 2011 at 02:10:18PM -0400, Mark Nottingham wrote:
> 
> On 24/07/2011, at 2:06 PM, Willy Tarreau wrote:
> >> 
> >> 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.
> 
> I don't understand. 

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.

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