- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 24 Jul 2011 13:55:11 -0400
- To: Willy Tarreau <w@1wt.eu>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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? Besides which, this would be introducing a requirement that makes several previously conformant implementations non-conformant. -- Mark Nottingham http://www.mnot.net/
Received on Sunday, 24 July 2011 17:55:35 UTC