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