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
"publication."
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.
--karl--