W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

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

From: Willy Tarreau <w@1wt.eu>
Date: Sun, 24 Jul 2011 20:15:08 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20110724181508.GX22405@1wt.eu>
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.


Received on Sunday, 24 July 2011 18:15:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC