Re: Snapshot-date
Tue, 19 Jul 1994 08:59:31 +0200

> >> They already do -- it's called the "Date:" header. How the cache managers
> >> interpret/use that information is what matters.
>> That's what I thought at first. It turns out that the "Date:" header
>> is very weakly defined in the RFCs and is likely to contain just about
>> anything from the date the document was created to the date it is sent
>> from the server. In other words, if "Date:" were used consistently, I
>> would agree that what I have proposed is redundant.
>Nonsense -- most of the HTTP2 spec is defined "weakly" and yet the
>WWW seems to get along quite well. The "Date:" header ALWAYS represents
>the timestamp when the rfc822-type message was generated.
>If any software is using it to mean something else, then that software
>is broken and must be fixed. Period.

I just watched the behaviour of a caching CERN server. It does, in
fact, do as you say. The "Date: " line indicates when the item came
from the cache and the "Last-Modified: " line indicates the date of

And I also took a look at RFC822. It is very vague about how the
Date: line is to be used.

So, if you so strongly disagree that a "snapshot-date: " line is
identical in semantics to the existing "Date: " line, then it would be
wise to write that down in the http specification. Otherwise somone will
do it differently.

I would prefer to avoid the uncertainty and define something new that is
not ambiguous and does not have a long history of prior use.

>All HTTP servers that I know of follow this behavior consistently.
>As far as I know, all cache managers do the same -- if they don't,
>it is likely because they are a simple hack (i.e. saving the entire
>message in a file rather than separating the headers from the content)
>and such are not likely to be protocol-compliant to begin with.

"protocol-complient" with a "weak spec" is kind of an oxymoron. :-)

>> I'm not sure that it would be safe to build on "Date:". That's why I am
>> proposing a new header line with a very specific definition.

>It is far easier to fix the non-compliant servers (if there are any) than
>it is to add to them a new "feature" which is, by definition, completely
>redundant. If the definition of "Date:" in the HTTP2 spec is weak, then
>propose the specific wordage that will strengthen the definition. I am
>sure that, if the definition is accurate, it will be added to the HTTP2
>spec (the people at CERN are always willing to improve the WWW
>documentation ... they just rarely have the time to do it themselves).

Adding a comment to the protocol spec would be fine by me.