Reload operations (original) (raw)

Document how to achieve each of:

(reload) I want a firsthand response from the origin server.
(revalidate) I want a response that has been validated with the origin server after I made this request.
(specific revalidate) I want to validate my own cached response with the origin server.
(conditional method) I want to validate my own cached response, but I'll accept a non-authoritative answer (i.e., from a cache that has a still-fresh copy with a matching validator)
(normal method) I want a fresh response.

Roy's draft:

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

   Proposal:  

       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.1

I'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?).