[10350] in www-talk@info.cern.ch
Re: If-Modified-Since No Longer Cool?
daemon@ATHENA.MIT.EDU (Inigo Lopez)
Tue Oct 8 04:36:43 1996
To: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: Ari Luotonen <luotonen@netscape.com>,
jjames@firstfloor.com (John W. James), www-talk@w3.org
In-Reply-To: <199610072057.QAA23275@anansi.w3.org>
Date: Tue, 08 Oct 1996 10:26:37 +0200
From: Inigo Lopez <ilopez@fundesco.es>
Resent-From: www-talk@w3.org
En fecha/On Mon, 07 Oct 1996 16:57:49 -0400 Henrik Frystyk Nielsen =
expuso/wrote:
> Hopefully, etags will be the preferred way to validate caches in HTTP/1=
=2E1
> applications. That way, we avoid the resolution being 1 sec, millions
> of different date/time formats, the 2000 problem, time zones, and lack =
of
> time synchronization.
I haven't read about etags yet, but I still think using If-Modified-Since=
doesn't have the problems you mention:
- resolution being 1 sec: seems good enough for me, taking into account 1=
sec
is a lot less than the average time between document modifications.
- millions of different date/time formats: there are *only* three date fo=
rmats
allowed in HTTP (for compatibility issues), and *only* one is encouraged
- the 2000 problem: it is not a problem if you use the suggested time for=
mat,
defined in RFC 822 (updated by RFC 1123) which uses a 4 digit year.
- time zones: the only time zone allowed is GMT
- lack of time synchronization: there is no need for it. The client must =
use
date values returned by the server, even if they don't match its internal=
clock. This date is interpreted in the server=B4s understanding of time.
I just liked the simplicity of the Last-Modified/If-Modified-Since mechan=
ism
for cache implementation.
I=F1igo
--
O I=F1igo L=F3pez C=EDa ilopez@fundesco.es
o O Fundesco - Dpto. Redes
. o O Plaza de la Independencia, 6 Tel: +34-1-3300735
. o 28001 Madrid Fax: +34-1-3300675
. Spain
