Question

I have searched cache topics and i ended up in the following

<meta http-equiv="Cache-control" content="description">

description

Public - may be cached in public shared caches
Private - may only be cached in private cache
no-Cache - may not be cached
no-Store - may be cached but not archived

What do they really mean

1.Does public shared caches mean files will be downloaded from proxy caches and gateway caches

2.Does private caches mean files referred in browser caches or caches stored at client system

3.When the description is set to no-Cache does it going to load new version from the web server.New files will be downloaded each and every time the page loads.

4.What do they really mean when they say not archived.

Kindly Explain in brief on how cache works instead of explaining public means accessible by everyone and private means limited access.

Answer 1

Quote from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

14.9.1 What is Cacheable

By default, a response is cacheable if the requirements of the request
method, request header fields, and the response status indicate that
it is cacheable. Section 13.4 summarizes these defaults for
cacheability. The following Cache-Control response directives allow an
origin server to override the default cacheability of a response:

public

Indicates that the response MAY be cached by any cache, even if it would normally be non-cacheable or cacheable only within a non- shared
cache. (See also Authorization, section 14.8, for additional details.)

private

Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an
origin server to state that the specified parts of the
response are intended for only one user and are not a valid response for requests by other users. A private (non-shared) cache MAY
cache the response.

Note: This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message
content. no-cache

If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request
without successful revalidation with the origin server. This allows an
origin server to prevent caching even by caches that have been
configured to return stale responses to client requests.

If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request,
subject to any other restrictions on caching. However, the specified
field-name(s) MUST NOT be sent in the response to a subsequent request
without successful revalidation with the origin server. This allows an
origin server to prevent the re-use of certain header fields in a
response, while still allowing caching of the rest of the response.

Note: Most HTTP/1.0 caches will not recognize or obey this directive.

14.9.2 What May be Stored by Caches

no-store

The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for
example, on backup tapes). The no-store directive applies to the
entire message, and MAY be sent either in a response or in a request.

If sent in a request, a cache MUST NOT store any part of either this
request or any response to it. If sent in a response, a cache MUST NOT
store any part of either this response or the request that elicited
it. This directive applies to both non- shared and shared caches.
“MUST NOT store” in this context means that the cache MUST NOT
intentionally store the information in non-volatile storage, and MUST
make a best-effort attempt to remove the information from volatile
storage as promptly as possible after forwarding it.

Even when this directive is associated with a response, users might explicitly store such a response outside of the caching system
(e.g., with a “Save As” dialog). History buffers MAY store such
responses as part of their normal operation.

The purpose of this directive is to meet the stated requirements of certain users and service authors who are concerned about
accidental releases of information via unanticipated accesses to cache
data structures. While the use of this directive might improve privacy
in some cases, we caution that it is NOT in any way a reliable or
sufficient mechanism for ensuring privacy. In particular, malicious or
compromised caches might not recognize or obey this directive, and
communications networks might be vulnerable to eavesdropping.