Roy,
The text in 10.8 of draft-ietf-http-v11-spec-01.html seems
to indicate that no-cache from a client to a server always requests
an authoritative version:
"The 'no-cache' directive on a request message requires any cache to
forward the request toward the origin server even if it has a cached
copy of what is being requested. This allows a client to insist upon
receiving an authoritative response to its request. It also allows a
client to refresh a cached copy which is known to be corrupted or stale."
If including an "If-Modified-Since" modifies that behavior to
mean that the client is request an authoritative copy only if the copy
on the server has been modified since some date, then we need to say
so in the text describing cache-control. I don't really think it
should mean that, frankly; no-cache already over-rides the other
cache-control directives, and it makes sense to me for it to override
"If-Modified-Since".
This, of course, makes it effectively a "Reload" command when
sent from the client. Using that term for the client-initiated
direction and "no-cache" for the server-initiated direction seems to
clarify a key difference between the behavior expected of the cache
when receiving this directive. Would it break any existing
implementations to make that change?
On a related note, does cache-control: max-age 0 also force
a reload (by asking for a copy of the resource that is no older than
0 seconds old?).
Regards,
Ted Hardie
NASA Science Internet
>
> Ted writes:
> > I believe switching to cache-control: reload from clients and
> > cache-control: no-cache would solve this particular confusion.
>
> No, it wouldn't. For example, the following is a Reload:
>
> GET / HTTP/1.1
> Cache-control: no-cache
>
> and the following is not
>
> GET / HTTP/1.1
> Cache-control: no-cache
> If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT
>
> The no-cache directive does not mean "Reload" -- it never has (even when
> used in Pragma).
>
> .....Roy
>