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
|
NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.
|
|
|
|
HTTP General Headers
(Page 1 of 3)
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.
Cache-Control
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 stalethis 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.
|
If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support! |
|
|
Home -
Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.
|