.

2 Response Headers
HTTP servers use headers in the response message
to specify how content is being returned and how it
should be handled. If you are using IE, you will have
seen the following headers returned with the image in
Example 2:

Cache-Control: no-cache

This header indicates whether the resource may be

cached by the browser or any immediate caches. The
value no-cache disables all caching. (See 5. Caching
for more information)
Content-Length: 2748

This header contains the length in bytes of the

resource (i.e. the gif image) that follows the headers.

Content-Type: image/gif

The content is in GIF format.

Date: Wed, 4 Oct 2004 12:00:00 GMT

This is the current date and time on the web server.

Expires: -1
The Expires header specifies when the content
should be considered to be out of date. The value -1
indicates that the content expires immediately and
would have to be re-requested before being
displayed again.
Pragma: no-cache

The browser may be connecting to the server via

HTTP/1.0 proxies or caches, that do not support
the Cache-Control header. Setting Pragma to no-
cache header prevents HTTP/1.0 caches from
storing the content.
Server: Microsoft-IIS/6.0

The web server is an IIS 6 web server.

X-AspNet-Version: 2.0.50727

The web server is running ASP.NET 2.0

Responses
Field name Description Example

Accept- What partial content range Accept-Ranges: bytes

Ranges types this server supports
Content-
The language the content is in Content-Language: da
Language

Content- An alternate location for the Content-Location: /index.htm

Location returned data

Content-
The mime type of this content Content-Type: text/html; char
Type

The date and time that the

Date Date: Tue, 15 Nov 1994 08:12:
message was sent

The last modified date for the

Last- Last-Modified: Tue, 15 Nov 19
requested object, in RFC 2822 GMT
Modified
format

Used in redirection, or when a

Location:
Location new resource has been http://www.w3.org/pub/WWW/Peo

created.
Server: Apache/1.3.27 (Unix)
Server A name for the server Hat/Linux)

Example session
Below is a sample conversation between an HTTP
client and an HTTP server running
on www.example.com, port 80.
[edit]Client request
GET /index.html HTTP/1.1
Host: www.example.com

A client request (consisting in this case of the request

line and only one header) is followed by a blank line,
so that the request ends with a double newline, each
in the form of a carriage return followed by a line
feed. The "Host" header distinguishes between
various DNS names sharing a single IP address,
allowing name-based virtual hosting. While optional
in HTTP/1.0, it is mandatory in HTTP/1.1.
[edit]Server response
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8

A server response is followed by a blank line and text

of the requested page. The ETag (entity tag) header
is used to determine if a cached version of the
requested resource is identical to the current version
of the resource on the server. Content-Type specifies
the Internet media type of the data conveyed by the
http message, while Content-Length indicates its
length in bytes. The HTTP/1.1 webserver publishes
its ability to respond to requests for certain byte
ranges of the document by setting the
header Accept-Ranges: bytes. This is useful if the
client needs to have only certain portions[15] of a
resource sent by the server, which is called byte
serving. When Connection: close is sent in a header,
it means that the web server will close
the TCP connection immediately after the transfer of
this response.

5. HTTP Caching
Web pages often contain content that remains
unchanged for long periods of time. For example, an
image containing a company logo may be used
without modification for many years. It is wasteful in
terms of bandwidth and round trips to repeatedly
download images or other content that is not
regularly updated.

HTTP supports caching so that content can be stored

locally by the browser and reused when required. Of
course, some types of data such as stock prices and
weather forecasts are frequently changed and it is
important that the browser does not display stale
versions of these resources. By carefully controlling
caching, it is possible to reuse static content and
prevent the storage of dynamic data.
Browser caching is controlled by the use of
the Cache-Control, Last-
Modified and Expires response headers.

5.1 Preventing Caching

Servers set the Cache-Control response header
to no-cache to indicate that content should not be
cached by the browser:
Cache-Control: no-cache

Also, the Pragma header is also often used to stop

caching by HTTP 1.0 proxies as they do not support
theCache-Control header:
Pragma: no-cache

For a full description of Cache-Control and the other

values it supports please consult the HTTP 1.1
specification.

5.2 Allowing Caching

The Cache-Control header can be set to one of the
following values to allow caching:
<absen t> If the Cache-Control header is not set, then any cache may store the content.

private The content is intended for use by a single user and should only be cached
locally in the browser.
public The content may be cached in public caches (e.g. shared proxies) and private
browser caches.

If the browser is to make effective use of cached

content, two extra pieces of information should be
supplied. The first is the modification date/time of the
content. The server supplies this in the Last-
Modified response header:
Last-Modified: Wed, 15 Sep 2004 12:00:00
GMT

The browser keeps this value with the cached entry

so that it can check the server for changes when a
page is first visited in a browser session or the user
requests a page update (e.g. presses F5 in IE).

The second piece of information is the expiration

date, that is specified with the Expires header:
Expires: Sun, 17 Jan 2038 19:14:07 GMT

If a cached entry has a valid expiration date the

browser can reuse the content without having to
contact the server at all when a page or site is
revisited. This greatly reduces the number of network
round trips for frequently visited pages. For example,
the Google logo is set to expire in 2038 and will only
be downloaded on your first visit to google.com or if
you have emptied your browser cache. If they ever
want to change the image they can use a different
image file name or path.

Example 5
The images in this example demonstrate different levels
of caching. It is worth trying the following actions in
Internet Explorer to investigate how well these images are
cached:

 Try using the back and forward buttons

 Refreshing the page
 Opening a new instance of IE to create a new
browser session and re-visiting this page
Image A: This image is never cached and is always downloaded; even
with back/forward buttons.
Image B: This image can be cached but has no expiration or modification
date. Therefore it is always downloaded when the page is first
visited in a new browser session or if the user refreshes the
page.
Image C: This image can be cached and has a modification date but no
expiration date. Therefore it is always checked but not
downloaded when the page is first visited in a browser session
or if the user refreshes the page.
Image D: This image can be cached and has an expiration date set to
2038. The browser can reuse the image in a new browser
session without having to send any request to the server. It can
always be re-read from cache unless the cache is cleared, or the
user requests a forced update with Ctrl + F5.