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.

The Book is Here... and Now On Sale!

Read offline with no ads or diagram watermarks!
The TCP/IP Guide

Custom Search







Table Of Contents  The TCP/IP Guide
 9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)
      9  TCP/IP Key Applications and Application Protocols
           9  TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)
                9  TCP/IP World Wide Web (WWW, "The Web") and the Hypertext Transfer Protocol (HTTP)
                     9  TCP/IP Hypertext Transfer Protocol (HTTP)
                          9  HTTP Message Headers

Previous Topic/Section
HTTP Message Headers
Previous Page
Pages in Current Topic/Section
1
23
Next Page
HTTP Request Headers
Next Topic/Section

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


Previous Topic/Section
HTTP Message Headers
Previous Page
Pages in Current Topic/Section
1
23
Next Page
HTTP Request Headers
Next Topic/Section

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!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



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.