Re: last-seen

• Mail folder: WWW Talk Jan 94-present
• Next message: Roy T. Fielding: "Re: If-Modified-Since and 304"
• Previous message: Peter Lister, Cranfield Computer Centre: "Authentication *before* GET?"
• Maybe in reply to: Bert Bos: "Re: last-seen"

Errors-To: listmaster@www0.cern.ch
Date: Fri, 11 Mar 1994 14:26:45 --100
Message-id: <9403111305.AA21357@hotsand.dacsand>
Errors-To: listmaster@www0.cern.ch
Reply-To: ellson@hotsand.att.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: ellson@hotsand.att.com
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: last-seen
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1316

> From: Bert Bos <bert@let.rug.nl>
> 
>  |> b) is the date in GMT?
>  |
>  |Don't care.
> [...]
>  |The receiving cache should not attempt to understand the
>  |semantics of the "Last-modified" date.  It should be treated as a
>  |tag provided by the server that the server can match against when it
>  |is sent back in the "If-Modified-Since" field.
> 
> But presumably the requesting program only asks for the document if
> the version it has is expired. That means it must have interpreted the
> date & time.

If the document has expired or if the document has no "Expires" header
field.  In either case the "Last modified" date is separate.

> Isn't it better then to let the receiving cache generate
> a valid date & time from its internal representation, instead of
> keeping the original date string around?

Perhaps this is a local implementation issue rather that a protocol
issue?  I agree with Gary Adams that it might be better if the
specification treated the string sent back in the "If-Modified-Since"
field as an "opaque server cookie."  That way, the mechanism for cache
coherency can be independent of time representation.  However, since the
receiving system may use the "Last modified date" for other purposes,
the string isn't always opaque to the receiving system.

John Ellson
AT&T Bell Labs