Re: Issue 163, was: Meaning of invalid but well-formed dates

Julian Reschke wrote:
>     * HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date 
> which appears to be more than 50 years in the future is in fact in the 
> past (this helps solve the "year 2000" problem).
> 
> -> 50 years from when? Does the semantics of the message depend on when 
> you look at it?

One could just assume that systems with such long time ranges simply
won't transmit RFC-850 dates _over HTTP_.  Then the "wraparound"
comparison works: similar to the 32-bit wraparound sequence comparison
used by TCP and many other systems.

For archived email and news, of course 2-digit years will continue to
mean the same for a long time into the future, and should not be used
for new messages.

It would be tidy to be consistent with email and news interpretation
of 2-digit years, whatever it is, which presumably doesn't depend on
when you look at it.

But since we never expect to see 2-digit years in HTTP, and if there
are any implementations which do, they can be expected to disappear,
either interpretation should be fine.

... Unless there is some attack on HTTP possible by taking advantage
of a message's time being interpreted differently on different agents
that it passes through.  Proxies don't rewrite the date header into
standard form - do they?

-- Jamie

Received on Tuesday, 19 May 2009 14:02:30 UTC