Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
HTTP general headers are so named because unlike the other three categories, they are not specific to any particular kind of message or message component (request, response or message entity). General headers are used primarily to communicate information about the message itself, as opposed to what content it carries. They provide general information and control how a message is processed and handled.
Despite not being specific to either requests or replies, some general headers are used either mostly or entirely in one or the other type of message. There are also some general headers that can appear in either a request or a reply, but have a somewhat different meaning in each.
Specifies directives that manage how caching is performed either for an HTTP request or response. These directives affect the handling of a request or response by all devices in the request/response chain from the HTTP client, through any present intermediaries, to the HTTP server (or the other way, from the server, through intermediaries, to the client). They override any default caching behavior performed by a device. See the topic on caching for a full exposition of the subject.
There are a dozen individual directives that can appear in this header, the full details of which can be found in RFC 2616. Even though this is a general header, some directives can appear only in a request or a response. Some also include an additional parameter, such as a number of seconds, that control their interpretation. Table 276 provides a brief summary of the different Cache-Control options and how they are used.
Note that only one directive may appear in a Cache-Control header, but more than one such header can appear in a message.
Table 276: HTTP Cache-Control Directives
Cache-Control Directive
HTTP Message Type
Description
no-cache
Request or Response
When present, forces a caching
device to forward any subsequent requests for the same content to the
server for revalidation. That is, the cache must check with the server
to ensure that the cached data is still valid.
Also see the Pragma header description, for an alternative way
of accomplishing the same thing.
public
Response
Indicates that the response may be cached by any cache, including a shared one (a cache used by many clients). See the topic on caching for more details on shared caches.
private
Response
Specifies that the response is intended for only a particular user and should not be placed into a shared cache.
no-store
Request or Response
Specifies that the entire request or response should not be stored in a cache. This is used sometimes to prevent the storing of sensitive documents in caches where unauthorized people might be able to access them. However, as the HTTP standard points out, this is really a very rudimentary security measure and should not be trusted a great deal (since a malicious cache operator could simply ignore the directive.)
max-age
Request or Response
In a request, indicates that the client is willing to accept a response whose age is no greater than the value specified. In a response, indicates the maximum age of the response before it is considered “stale”—this is an alternative to the use of the Expires header and takes precedence over it.
s-maxage
Response
If present, this directive specifies the maximum age for shared caches receiving the response. Private caches (ones that serve only a single client) use the max-age value described just above.
min-fresh
Request
Specifies that the client wants a response that is not only not stale at the time the request is received, but that will remain “fresh” for the specified number of seconds.
max-stale
Request
If sent without a parameter, indicates that the client is willing to accept a stale reply (one that has expired). If a numeric parameter is included, it indicates how stale, in seconds, the response may be.
only-if-cached
Request
Used only in special circumstances, this directive forces the reply to come from a cache only; the content may not come from the actual specified HTTP server.
must-revalidate
Response
Instructs a cache to revalidate its cache entry for the given response with the original server after it becomes stale. This is used to prevent problems with certain types of transactions that can occur if stale cache entries are sent to a client (perhaps as a result of the client using the max-stale directive.)
proxy-revalidate
Response
Similar to must-revalidate, but applies only to proxies that service many users. Private caches, such as those on individual client computers, are not affected.
no-transform
Request or Response
Some caches will, by default, change the form in which certain cached entries are stored, to save space or improve performance. In cases where this might cause problems, the client or server can use this directive to request that this transformation not be performed.