A = Reload GET /home.html HTTP/1.1 Cache-control: no-cache B = Revalidate GET /home.html HTTP/1.1 Cache-control: max-age=0 C = Specific revalidate GET /home.html HTTP/1.1 If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT Cache-control: no-cache D = Conditional method GET /home.html HTTP/1.1 If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT E = Normal method GET /home.html HTTP/1.1
A = Reload GET /home.html HTTP/1.1 Cache-control: reload B = Revalidate GET /home.html HTTP/1.1 Cache-control: revalidate C = Specific revalidate GET /home.html HTTP/1.1 If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT Cache-control: revalidate D = Conditional method GET /home.html HTTP/1.1 If-Modified-Since: Thu, 15 Feb 1996 15:05:20 GMT E = Normal method GET /home.html HTTP/1.1I'll state for the record that, while I don't think it makes a big difference, I think it is unnecessarily confusing and absolutely without pragmatic value to use the same tokens (e.g., no-cache or max-age) on both request and response, especially when their meanings are significantly different depending on the direction.
While it is true that the current practice with "Pragma: no-cache" does make this error, I do not think that this makes it any more attractive to compound the error in a brand-new header ("Cache-control:").
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?).