Skip to main content

 Glossary

A-Z glossary of PageSeeder concepts

Cache-Control

There are multiple levels at which PageSeeder utilizes caching to improve performance. This entry is specifically oriented to HTTP caching.

Cache-Control is an HTTP header value, used by both the user agent (the browser) and the server (and proxy servers), to control how the browser caches content served by PageSeeder. This can optimize performance and conserve bandwidth.

PageSeeder uses two types of cache control, depending on the type of resources being requested.

Volatile resources

For all HTML, PageSeeder explicitly disables browser caching with the following HTTP response headers:

Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache

The Cache-Control header with a value of no-cache prevents caching by browsers and proxies, ensuring that the user always gets a fresh copy directly from the server.

The Expires header is only needed for old proxy servers which don’t support HTTP/1.1.

While this configuration ensures currency of resources, it is costly in terms of bandwidth and CPU and shouldn’t be used when it isn’t necessary.

Static resources

For static resources (such as CSS, JavaScript, and some images), PageSeeder uses HTTP response headers that allow caching by browsers and proxy servers.

For example:

Expires:        Fri, 03 Jun 2011 05:02:07 GMT
Cache-Control:  max-age=86400, must-revalidate
Etag:           W/"4845-1267586931000-gzip"

The Cache-Control header tells the browser that the resource can be cached for up to 86400 seconds (= 24 hours), then it must be checked for currency (revalidated).

Revalidation is done by the client returning the Etag from the original header back to the server.

The Expires header is only needed for old proxy servers which don’t understand HTTP/1.1, and it should be overridden by the Cache-Control.

When the PageSeeder Server revalidates a resource (and the request is successful), it returns either of these:

200 (OK)Including the content if the resource is new or the server is unable to determine whether the browser has a copy
304 (Not Modified)Headers without the content assuming that the browser has a copy

The browser doesn’t attempt to connect to the server while the resource is considered fresh.

See also Hypertext Transfer Protocol -- HTTP/1.1 .

Browser reload

Following are the different ways the browser retrieves resources. These are dependent on the action from the user.

Link or
URL in address bar
Retrieves the resource in the most efficient manner: from cache if possible, otherwise from the server. Sends an Etag if one is available for the resource.
Reload or 
F5 or 
CTRL+R
Asks the server to revalidate the cached copy. This request to the server contains the HTTP header Cache-Control: 0
SHIFT+Reload or
 CTRL+F5  or 
SHIFT+CTRL+R
This expects the browser to discard the cached resource and request a new version from the server, forcing a reload. The HTTP headers include Cache-Control: no-cache to ensure that no cache copy is given by intermediaries.
Created on , last edited on