You're right. "Expires" should refer to the client's view of things.
I'll correct the programs.
(One thing that clients and proxies do need to be careful of is to use
caching only for the idempotent HTTP methods, in particular never for
POST, unless they know that the request body is exactly the same too.)
> > Nevertheless, it would not make sense to try to fetch an "updated"
> > version of such a document.
>
> As you say, this view causes problems. I suggest thinking of the Expires:
> header as meaning "a cache can validly serve this file on request until:"
I think I was confused by the usage of some of the terms in the spec.
To say that data obtained on the Web is "invalid" should mean that the
association between the data and the URI used to retrieve it has been
broken. But this may happen either because the URI has new data, or
because it has become defunct and has _no_ data. "Expires" really only
covers the first case, and the spec should make that clear.
Similarly, a "dynamic" URI, I'd think, would be one which produces
non-constant data. But again, there are two ways this can happen.
One is that the URI is actually serving _time-dependent_ data; the
other is that the URI may be accessed with by HTTP method like POST,
which accepts a variable request body that affects the output.
The spec's "strong encouragement" to authors of dynamic documents
is really directed towards authors of time-dependent documents.