|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head>
|
|
Packit |
90a5c9 |
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type" />
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
|
Packit |
90a5c9 |
This file is generated from xml source: DO NOT EDIT
|
|
Packit |
90a5c9 |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
|
Packit |
90a5c9 |
-->
|
|
Packit |
90a5c9 |
<title>Caching Guide - Apache HTTP Server Version 2.4</title>
|
|
Packit |
90a5c9 |
<link href="./style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
|
|
Packit |
90a5c9 |
<link href="./style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
|
|
Packit |
90a5c9 |
<link href="./style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link rel="stylesheet" type="text/css" href="./style/css/prettify.css" />
|
|
Packit |
90a5c9 |
<script src="./style/scripts/prettify.min.js" type="text/javascript">
|
|
Packit |
90a5c9 |
</script>
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
<link href="./images/favicon.ico" rel="shortcut icon" /></head>
|
|
Packit |
90a5c9 |
<body id="manual-page">
|
|
Packit |
90a5c9 |
Modules | Directives | FAQ | Glossary | Sitemap
|
|
Packit |
90a5c9 |
Apache HTTP Server Version 2.4
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Apache > HTTP Server > Documentation > Version 2.4
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Available Languages: en |
|
|
Packit |
90a5c9 |
fr |
|
|
Packit |
90a5c9 |
tr
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
This document supplements the mod_cache,
|
|
Packit |
90a5c9 |
mod_cache_disk, mod_file_cache and htcacheclean reference documentation.
|
|
Packit |
90a5c9 |
It describes how to use the Apache HTTP Server's caching features to accelerate web and
|
|
Packit |
90a5c9 |
proxy serving, while avoiding common problems and misconfigurations.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
 Three-state RFC2616 HTTP caching
|
|
Packit |
90a5c9 |
Cache Setup Examples
|
|
Packit |
90a5c9 |
General Two-state Key/Value Shared Object Caching
|
|
Packit |
90a5c9 |
Specialized File Caching
|
|
Packit |
90a5c9 |
Security Considerations
|
|
Packit |
90a5c9 |
See also
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The Apache HTTP server offers a range of caching features that
|
|
Packit |
90a5c9 |
are designed to improve the performance of the server in various
|
|
Packit |
90a5c9 |
ways.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Three-state RFC2616 HTTP caching
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
mod_cache
|
|
Packit |
90a5c9 |
and its provider modules
|
|
Packit |
90a5c9 |
mod_cache_disk
|
|
Packit |
90a5c9 |
provide intelligent, HTTP-aware caching. The content itself is stored
|
|
Packit |
90a5c9 |
in the cache, and mod_cache aims to honor all of the various HTTP
|
|
Packit |
90a5c9 |
headers and options that control the cacheability of content
|
|
Packit |
90a5c9 |
as described in
|
|
Packit |
90a5c9 |
Section
|
|
Packit |
90a5c9 |
13 of RFC2616.
|
|
Packit |
90a5c9 |
mod_cache
|
|
Packit |
90a5c9 |
is aimed at both simple and complex caching configurations, where
|
|
Packit |
90a5c9 |
you are dealing with proxied content, dynamic local content or
|
|
Packit |
90a5c9 |
have a need to speed up access to local files on a potentially
|
|
Packit |
90a5c9 |
slow disk.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Two-state key/value shared object caching
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The shared object cache API (socache)
|
|
Packit |
90a5c9 |
and its provider modules provide a
|
|
Packit |
90a5c9 |
server wide key/value based shared object cache. These modules
|
|
Packit |
90a5c9 |
are designed to cache low level data such as SSL sessions and
|
|
Packit |
90a5c9 |
authentication credentials. Backends allow the data to be stored
|
|
Packit |
90a5c9 |
server wide in shared memory, or datacenter wide in a cache such
|
|
Packit |
90a5c9 |
as memcache or distcache.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Specialized file caching
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
mod_file_cache
|
|
Packit |
90a5c9 |
offers the ability to pre-load
|
|
Packit |
90a5c9 |
files into memory on server startup, and can improve access
|
|
Packit |
90a5c9 |
times and save file handles on files that are accessed often,
|
|
Packit |
90a5c9 |
as there is no need to go to disk on each request.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
To get the most from this document, you should be familiar with
|
|
Packit |
90a5c9 |
the basics of HTTP, and have read the Users' Guides to
|
|
Packit |
90a5c9 |
Mapping URLs to the Filesystem and
|
|
Packit |
90a5c9 |
Content negotiation.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The HTTP protocol contains built in support for an in-line caching
|
|
Packit |
90a5c9 |
mechanism
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
described by section 13 of RFC2616, and the
|
|
Packit |
90a5c9 |
mod_cache module can be used to take advantage of
|
|
Packit |
90a5c9 |
this.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Unlike a simple two state key/value cache where the content
|
|
Packit |
90a5c9 |
disappears completely when no longer fresh, an HTTP cache includes
|
|
Packit |
90a5c9 |
a mechanism to retain stale content, and to ask the origin server
|
|
Packit |
90a5c9 |
whether this stale content has changed and if not, make it fresh
|
|
Packit |
90a5c9 |
again.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
An entry in an HTTP cache exists in one of three states:
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Fresh
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If the content is new enough (younger than its freshness
|
|
Packit |
90a5c9 |
lifetime), it is considered fresh. An
|
|
Packit |
90a5c9 |
HTTP cache is free to serve fresh content without making any
|
|
Packit |
90a5c9 |
calls to the origin server at all.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Stale
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If the content is too old (older than its freshness
|
|
Packit |
90a5c9 |
lifetime), it is considered stale. An
|
|
Packit |
90a5c9 |
HTTP cache should contact the origin server and check whether
|
|
Packit |
90a5c9 |
the content is still fresh before serving stale content to a
|
|
Packit |
90a5c9 |
client. The origin server will either respond with replacement
|
|
Packit |
90a5c9 |
content if not still valid, or ideally, the origin server will
|
|
Packit |
90a5c9 |
respond with a code to tell the cache the content is still
|
|
Packit |
90a5c9 |
fresh, without the need to generate or send the content again.
|
|
Packit |
90a5c9 |
The content becomes fresh again and the cycle continues.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The HTTP protocol does allow the cache to serve stale data
|
|
Packit |
90a5c9 |
under certain circumstances, such as when an attempt to freshen
|
|
Packit |
90a5c9 |
the data with an origin server has failed with a 5xx error, or
|
|
Packit |
90a5c9 |
when another request is already in the process of freshening
|
|
Packit |
90a5c9 |
the given entry. In these cases a Warning header
|
|
Packit |
90a5c9 |
is added to the response.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Non Existent
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If the cache gets full, it reserves the option to delete content
|
|
Packit |
90a5c9 |
from the cache to make space. Content can be deleted at any time,
|
|
Packit |
90a5c9 |
and can be stale or fresh. The htcacheclean tool can be
|
|
Packit |
90a5c9 |
run on a once off basis, or deployed as a daemon to keep the size
|
|
Packit |
90a5c9 |
of the cache within the given size, or the given number of inodes.
|
|
Packit |
90a5c9 |
The tool attempts to delete stale content before attempting to
|
|
Packit |
90a5c9 |
delete fresh content.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Full details of how HTTP caching works can be found in
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Section 13 of RFC2616.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Interaction with the Server
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The mod_cache module hooks into the server in two
|
|
Packit |
90a5c9 |
possible places depending on the value of the
|
|
Packit |
90a5c9 |
CacheQuickHandler directive:
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Quick handler phase
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
This phase happens very early on during the request processing,
|
|
Packit |
90a5c9 |
just after the request has been parsed. If the content is
|
|
Packit |
90a5c9 |
found within the cache, it is served immediately and almost
|
|
Packit |
90a5c9 |
all request processing is bypassed.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
In this scenario, the cache behaves as if it has been "bolted
|
|
Packit |
90a5c9 |
on" to the front of the server.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
This mode offers the best performance, as the majority of
|
|
Packit |
90a5c9 |
server processing is bypassed. This mode however also bypasses the
|
|
Packit |
90a5c9 |
authentication and authorization phases of server processing, so
|
|
Packit |
90a5c9 |
this mode should be chosen with care when this is important.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Requests with an "Authorization" header (for example, HTTP Basic
|
|
Packit |
90a5c9 |
Authentication) are neither cacheable nor served from the cache
|
|
Packit |
90a5c9 |
when mod_cache is running in this phase.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Normal handler phase
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
This phase happens late in the request processing, after all
|
|
Packit |
90a5c9 |
the request phases have completed.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
In this scenario, the cache behaves as if it has been "bolted
|
|
Packit |
90a5c9 |
on" to the back of the server.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
This mode offers the most flexibility, as the potential exists
|
|
Packit |
90a5c9 |
for caching to occur at a precisely controlled point in the filter
|
|
Packit |
90a5c9 |
chain, and cached content can be filtered or personalized before
|
|
Packit |
90a5c9 |
being sent to the client.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If the URL is not found within the cache, mod_cache
|
|
Packit |
90a5c9 |
will add a filter to the filter stack in order
|
|
Packit |
90a5c9 |
to record the response to the cache, and then stand down, allowing normal
|
|
Packit |
90a5c9 |
request processing to continue. If the content is determined to be
|
|
Packit |
90a5c9 |
cacheable, the content will be saved to the cache for future serving,
|
|
Packit |
90a5c9 |
otherwise the content will be ignored.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If the content found within the cache is stale, the
|
|
Packit |
90a5c9 |
mod_cache module converts the request into a
|
|
Packit |
90a5c9 |
conditional request. If the origin server responds with
|
|
Packit |
90a5c9 |
a normal response, the normal response is cached, replacing the content
|
|
Packit |
90a5c9 |
already cached. If the origin server responds with a 304 Not Modified
|
|
Packit |
90a5c9 |
response, the content is marked as fresh again, and the cached content
|
|
Packit |
90a5c9 |
is served by the filter instead of saving it.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Improving Cache Hits
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
When a virtual host is known by one of many different server aliases,
|
|
Packit |
90a5c9 |
ensuring that UseCanonicalName is
|
|
Packit |
90a5c9 |
set to On can dramatically improve the ratio of cache hits.
|
|
Packit |
90a5c9 |
This is because the hostname of the virtual-host serving the content is
|
|
Packit |
90a5c9 |
used within the cache key. With the setting set to On
|
|
Packit |
90a5c9 |
virtual-hosts with multiple server names or aliases will not produce
|
|
Packit |
90a5c9 |
differently cached entities, and instead content will be cached as
|
|
Packit |
90a5c9 |
per the canonical hostname.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Freshness Lifetime
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Well formed content that is intended to be cached should declare an
|
|
Packit |
90a5c9 |
explicit freshness lifetime with the Cache-Control
|
|
Packit |
90a5c9 |
header's max-age or s-maxage fields, or
|
|
Packit |
90a5c9 |
by including an Expires header.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
At the same time, the origin server defined freshness lifetime can
|
|
Packit |
90a5c9 |
be overridden by a client when the client presents their own
|
|
Packit |
90a5c9 |
Cache-Control header within the request. In this case,
|
|
Packit |
90a5c9 |
the lowest freshness lifetime between request and response wins.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
When this freshness lifetime is missing from the request or the
|
|
Packit |
90a5c9 |
response, a default freshness lifetime is applied. The default
|
|
Packit |
90a5c9 |
freshness lifetime for cached entities is one hour, however
|
|
Packit |
90a5c9 |
this can be easily over-ridden by using the CacheDefaultExpire directive.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If a response does not include an Expires header but does
|
|
Packit |
90a5c9 |
include a Last-Modified header, mod_cache
|
|
Packit |
90a5c9 |
can infer a freshness lifetime based on a heuristic, which can be
|
|
Packit |
90a5c9 |
controlled through the use of the CacheLastModifiedFactor directive.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
For local content, or for remote content that does not define its own
|
|
Packit |
90a5c9 |
Expires header, mod_expires may be used to
|
|
Packit |
90a5c9 |
fine-tune the freshness lifetime by adding max-age and
|
|
Packit |
90a5c9 |
Expires.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The maximum freshness lifetime may also be controlled by using the
|
|
Packit |
90a5c9 |
CacheMaxExpire.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
A Brief Guide to Conditional Requests
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
When content expires from the cache and becomes stale, rather than
|
|
Packit |
90a5c9 |
pass on the original request, httpd will modify the request to make
|
|
Packit |
90a5c9 |
it conditional instead.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
When an ETag header exists in the original cached
|
|
Packit |
90a5c9 |
response, mod_cache will add an
|
|
Packit |
90a5c9 |
If-None-Match header to the request to the origin server.
|
|
Packit |
90a5c9 |
When a Last-Modified header exists in the original
|
|
Packit |
90a5c9 |
cached response, mod_cache will add an
|
|
Packit |
90a5c9 |
If-Modified-Since header to the request to the origin
|
|
Packit |
90a5c9 |
server. Performing either of these actions makes the request
|
|
Packit |
90a5c9 |
conditional.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
When a conditional request is received by an origin server, the
|
|
Packit |
90a5c9 |
origin server should check whether the ETag or the Last-Modified
|
|
Packit |
90a5c9 |
parameter has changed, as appropriate for the request. If not, the
|
|
Packit |
90a5c9 |
origin should respond with a terse "304 Not Modified" response. This
|
|
Packit |
90a5c9 |
signals to the cache that the stale content is still fresh should be
|
|
Packit |
90a5c9 |
used for subsequent requests until the content's new freshness lifetime
|
|
Packit |
90a5c9 |
is reached again.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If the content has changed, then the content is served as if the
|
|
Packit |
90a5c9 |
request were not conditional to begin with.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Conditional requests offer two benefits. Firstly, when making such
|
|
Packit |
90a5c9 |
a request to the origin server, if the content from the origin
|
|
Packit |
90a5c9 |
matches the content in the cache, this can be determined easily and
|
|
Packit |
90a5c9 |
without the overhead of transferring the entire resource.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Secondly, a well designed origin server will be designed in such
|
|
Packit |
90a5c9 |
a way that conditional requests will be significantly cheaper to
|
|
Packit |
90a5c9 |
produce than a full response. For static files, typically all that is
|
|
Packit |
90a5c9 |
involved is a call to stat() or similar system call, to
|
|
Packit |
90a5c9 |
see if the file has changed in size or modification time. As such, even
|
|
Packit |
90a5c9 |
local content may still be served faster from the cache if it has not
|
|
Packit |
90a5c9 |
changed.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Origin servers should make every effort to support conditional
|
|
Packit |
90a5c9 |
requests as is practical, however if conditional requests are not
|
|
Packit |
90a5c9 |
supported, the origin will respond as if the request was not
|
|
Packit |
90a5c9 |
conditional, and the cache will respond as if the content had changed
|
|
Packit |
90a5c9 |
and save the new content to the cache. In this case, the cache will
|
|
Packit |
90a5c9 |
behave like a simple two state cache, where content is effectively
|
|
Packit |
90a5c9 |
either fresh or deleted.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
What Can be Cached?
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The full definition of which responses can be cached by an HTTP
|
|
Packit |
90a5c9 |
cache is defined in
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
RFC2616 Section 13.4 Response Cacheability, and can be summed up as
|
|
Packit |
90a5c9 |
follows:
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Caching must be enabled for this URL. See the CacheEnable and CacheDisable directives.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If the response has an HTTP status code other than 200, 203, 300,
|
|
Packit |
90a5c9 |
301 or 410 it must also specify an "Expires" or "Cache-Control" header.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The request must be a HTTP GET request.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If the response contains an "Authorization:" header, it must
|
|
Packit |
90a5c9 |
also contain an "s-maxage", "must-revalidate" or "public" option
|
|
Packit |
90a5c9 |
in the "Cache-Control:" header, or it won't be cached.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If the URL included a query string (e.g. from a HTML form GET
|
|
Packit |
90a5c9 |
method) it will not be cached unless the response specifies an
|
|
Packit |
90a5c9 |
explicit expiration by including an "Expires:" header or the max-age
|
|
Packit |
90a5c9 |
or s-maxage directive of the "Cache-Control:" header, as per RFC2616
|
|
Packit |
90a5c9 |
sections 13.9 and 13.2.1.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If the response has a status of 200 (OK), the response must
|
|
Packit |
90a5c9 |
also include at least one of the "Etag", "Last-Modified" or
|
|
Packit |
90a5c9 |
the "Expires" headers, or the max-age or s-maxage directive of
|
|
Packit |
90a5c9 |
the "Cache-Control:" header, unless the
|
|
Packit |
90a5c9 |
CacheIgnoreNoLastMod
|
|
Packit |
90a5c9 |
directive has been used to require otherwise.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If the response includes the "private" option in a "Cache-Control:"
|
|
Packit |
90a5c9 |
header, it will not be stored unless the
|
|
Packit |
90a5c9 |
CacheStorePrivate has been
|
|
Packit |
90a5c9 |
used to require otherwise.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Likewise, if the response includes the "no-store" option in a
|
|
Packit |
90a5c9 |
"Cache-Control:" header, it will not be stored unless the
|
|
Packit |
90a5c9 |
CacheStoreNoStore has been
|
|
Packit |
90a5c9 |
used.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
A response will not be stored if it includes a "Vary:" header
|
|
Packit |
90a5c9 |
containing the match-all "*".
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
What Should Not be Cached?
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
It should be up to the client creating the request, or the origin
|
|
Packit |
90a5c9 |
server constructing the response to decide whether or not the content
|
|
Packit |
90a5c9 |
should be cacheable or not by correctly setting the
|
|
Packit |
90a5c9 |
Cache-Control header, and mod_cache should
|
|
Packit |
90a5c9 |
be left alone to honor the wishes of the client or server as appropriate.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Content that is time sensitive, or which varies depending on the
|
|
Packit |
90a5c9 |
particulars of the request that are not covered by HTTP negotiation,
|
|
Packit |
90a5c9 |
should not be cached. This content should declare itself uncacheable
|
|
Packit |
90a5c9 |
using the Cache-Control header.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If content changes often, expressed by a freshness lifetime of minutes
|
|
Packit |
90a5c9 |
or seconds, the content can still be cached, however it is highly
|
|
Packit |
90a5c9 |
desirable that the origin server supports
|
|
Packit |
90a5c9 |
conditional requests correctly to ensure that
|
|
Packit |
90a5c9 |
full responses do not have to be generated on a regular basis.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Content that varies based on client provided request headers can be
|
|
Packit |
90a5c9 |
cached through intelligent use of the Vary response
|
|
Packit |
90a5c9 |
header.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Variable/Negotiated Content
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
When the origin server is designed to respond with different content
|
|
Packit |
90a5c9 |
based on the value of headers in the request, for example to serve
|
|
Packit |
90a5c9 |
multiple languages at the same URL, HTTP's caching mechanism makes it
|
|
Packit |
90a5c9 |
possible to cache multiple variants of the same page at the same URL.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
This is done by the origin server adding a Vary header
|
|
Packit |
90a5c9 |
to indicate which headers must be taken into account by a cache when
|
|
Packit |
90a5c9 |
determining whether two variants are different from one another.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If for example, a response is received with a vary header such as;
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Vary: negotiate,accept-language,accept-charset
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
mod_cache will only serve the cached content to
|
|
Packit |
90a5c9 |
requesters with accept-language and accept-charset headers
|
|
Packit |
90a5c9 |
matching those of the original request.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Multiple variants of the content can be cached side by side,
|
|
Packit |
90a5c9 |
mod_cache uses the Vary header and the
|
|
Packit |
90a5c9 |
corresponding values of the request headers listed by Vary
|
|
Packit |
90a5c9 |
to decide on which of many variants to return to the client.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The mod_cache module relies on specific backend store
|
|
Packit |
90a5c9 |
implementations in order to manage the cache, and for caching to disk
|
|
Packit |
90a5c9 |
mod_cache_disk is provided to support this.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Typically the module will be configured as so;
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
CacheRoot "/var/cache/apache/"
|
|
Packit |
90a5c9 |
CacheEnable disk /
|
|
Packit |
90a5c9 |
CacheDirLevels 2
|
|
Packit |
90a5c9 |
CacheDirLength 1
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Importantly, as the cached files are locally stored, operating system
|
|
Packit |
90a5c9 |
in-memory caching will typically be applied to their access also. So
|
|
Packit |
90a5c9 |
although the files are stored on disk, if they are frequently accessed
|
|
Packit |
90a5c9 |
it is likely the operating system will ensure that they are actually
|
|
Packit |
90a5c9 |
served from memory.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Understanding the Cache-Store
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
To store items in the cache, mod_cache_disk creates
|
|
Packit |
90a5c9 |
a 22 character hash of the URL being requested. This hash incorporates
|
|
Packit |
90a5c9 |
the hostname, protocol, port, path and any CGI arguments to the URL,
|
|
Packit |
90a5c9 |
as well as elements defined by the Vary header to ensure that multiple
|
|
Packit |
90a5c9 |
URLs do not collide with one another.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Each character may be any one of 64-different characters, which mean
|
|
Packit |
90a5c9 |
that overall there are 64^22 possible hashes. For example, a URL might
|
|
Packit |
90a5c9 |
be hashed to xyTGxSMO2b68mBCykqkp1w. This hash is used
|
|
Packit |
90a5c9 |
as a prefix for the naming of the files specific to that URL within
|
|
Packit |
90a5c9 |
the cache, however first it is split up into directories as per
|
|
Packit |
90a5c9 |
the CacheDirLevels and
|
|
Packit |
90a5c9 |
CacheDirLength
|
|
Packit |
90a5c9 |
directives.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
CacheDirLevels
|
|
Packit |
90a5c9 |
specifies how many levels of subdirectory there should be, and
|
|
Packit |
90a5c9 |
CacheDirLength
|
|
Packit |
90a5c9 |
specifies how many characters should be in each directory. With
|
|
Packit |
90a5c9 |
the example settings given above, the hash would be turned into
|
|
Packit |
90a5c9 |
a filename prefix as
|
|
Packit |
90a5c9 |
/var/cache/apache/x/y/TGxSMO2b68mBCykqkp1w.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The overall aim of this technique is to reduce the number of
|
|
Packit |
90a5c9 |
subdirectories or files that may be in a particular directory,
|
|
Packit |
90a5c9 |
as most file-systems slow down as this number increases. With
|
|
Packit |
90a5c9 |
setting of "1" for
|
|
Packit |
90a5c9 |
CacheDirLength
|
|
Packit |
90a5c9 |
there can at most be 64 subdirectories at any particular level.
|
|
Packit |
90a5c9 |
With a setting of 2 there can be 64 * 64 subdirectories, and so on.
|
|
Packit |
90a5c9 |
Unless you have a good reason not to, using a setting of "1"
|
|
Packit |
90a5c9 |
for CacheDirLength
|
|
Packit |
90a5c9 |
is recommended.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Setting
|
|
Packit |
90a5c9 |
CacheDirLevels
|
|
Packit |
90a5c9 |
depends on how many files you anticipate to store in the cache.
|
|
Packit |
90a5c9 |
With the setting of "2" used in the above example, a grand
|
|
Packit |
90a5c9 |
total of 4096 subdirectories can ultimately be created. With
|
|
Packit |
90a5c9 |
1 million files cached, this works out at roughly 245 cached
|
|
Packit |
90a5c9 |
URLs per directory.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Each URL uses at least two files in the cache-store. Typically
|
|
Packit |
90a5c9 |
there is a ".header" file, which includes meta-information about
|
|
Packit |
90a5c9 |
the URL, such as when it is due to expire and a ".data" file
|
|
Packit |
90a5c9 |
which is a verbatim copy of the content to be served.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
In the case of a content negotiated via the "Vary" header, a
|
|
Packit |
90a5c9 |
".vary" directory will be created for the URL in question. This
|
|
Packit |
90a5c9 |
directory will have multiple ".data" files corresponding to the
|
|
Packit |
90a5c9 |
differently negotiated content.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Maintaining the Disk Cache
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The mod_cache_disk module makes no attempt to
|
|
Packit |
90a5c9 |
regulate the amount of disk space used by the cache, although it
|
|
Packit |
90a5c9 |
will gracefully stand down on any disk error and behave as if the
|
|
Packit |
90a5c9 |
cache was never present.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Instead, provided with httpd is the htcacheclean tool which allows you
|
|
Packit |
90a5c9 |
to clean the cache periodically. Determining how frequently to run htcacheclean and what target size to
|
|
Packit |
90a5c9 |
use for the cache is somewhat complex and trial and error may be needed to
|
|
Packit |
90a5c9 |
select optimal values.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
htcacheclean has two modes of
|
|
Packit |
90a5c9 |
operation. It can be run as persistent daemon, or periodically from
|
|
Packit |
90a5c9 |
cron. htcacheclean can take up to an hour
|
|
Packit |
90a5c9 |
or more to process very large (tens of gigabytes) caches and if you are
|
|
Packit |
90a5c9 |
running it from cron it is recommended that you determine how long a typical
|
|
Packit |
90a5c9 |
run takes, to avoid running more than one instance at a time.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
It is also recommended that an appropriate "nice" level is chosen for
|
|
Packit |
90a5c9 |
htcacheclean so that the tool does not cause excessive disk io while the
|
|
Packit |
90a5c9 |
server is running.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
<dfn>Figure 1</dfn>: Typical
|
|
Packit |
90a5c9 |
cache growth / clean sequence.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Because mod_cache_disk does not itself pay attention
|
|
Packit |
90a5c9 |
to how much space is used you should ensure that
|
|
Packit |
90a5c9 |
htcacheclean is configured to
|
|
Packit |
90a5c9 |
leave enough "grow room" following a clean.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Using the mod_cache_socache module, mod_cache
|
|
Packit |
90a5c9 |
can cache data from a variety of implementations (aka: "providers"). Using the
|
|
Packit |
90a5c9 |
mod_socache_memcache module, for example, one can specify that
|
|
Packit |
90a5c9 |
memcached is to be used as the
|
|
Packit |
90a5c9 |
the backend storage mechanism.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Typically the module will be configured as so:
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
CacheEnable socache /
|
|
Packit |
90a5c9 |
CacheSocache memcache:memcd.example.com:11211
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Additional memcached servers can be specified by
|
|
Packit |
90a5c9 |
appending them to the end of the CacheSocache memcache:
|
|
Packit |
90a5c9 |
line separated by commas:
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
CacheEnable socache /
|
|
Packit |
90a5c9 |
CacheSocache memcache:mem1.example.com:11211,mem2.example.com:11212
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
This format is also used with the other various mod_cache_socache
|
|
Packit |
90a5c9 |
providers. For example:
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
CacheEnable socache /
|
|
Packit |
90a5c9 |
CacheSocache shmcb:/path/to/datafile(512000)
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
CacheEnable socache /
|
|
Packit |
90a5c9 |
CacheSocache dbm:/path/to/datafile
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The Apache HTTP server offers a low level shared object cache for
|
|
Packit |
90a5c9 |
caching information such as SSL sessions, or authentication credentials,
|
|
Packit |
90a5c9 |
within the socache interface.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Additional modules are provided for each implementation, offering the
|
|
Packit |
90a5c9 |
following backends:
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
mod_socache_dbm
|
|
Packit |
90a5c9 |
DBM based shared object cache.
|
|
Packit |
90a5c9 |
mod_socache_dc
|
|
Packit |
90a5c9 |
Distcache based shared object cache.
|
|
Packit |
90a5c9 |
mod_socache_memcache
|
|
Packit |
90a5c9 |
Memcache based shared object cache.
|
|
Packit |
90a5c9 |
mod_socache_shmcb
|
|
Packit |
90a5c9 |
Shared memory based shared object cache.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The mod_authn_socache module allows the result of
|
|
Packit |
90a5c9 |
authentication to be cached, relieving load on authentication backends.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The mod_ssl module uses the socache interface
|
|
Packit |
90a5c9 |
to provide a session cache and a stapling cache.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
On platforms where a filesystem might be slow, or where file
|
|
Packit |
90a5c9 |
handles are expensive, the option exists to pre-load files into
|
|
Packit |
90a5c9 |
memory on startup.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
On systems where opening files is slow, the option exists to
|
|
Packit |
90a5c9 |
open the file on startup and cache the file handle. These
|
|
Packit |
90a5c9 |
options can help on systems where access to static files is
|
|
Packit |
90a5c9 |
slow.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The act of opening a file can itself be a source of delay, particularly
|
|
Packit |
90a5c9 |
on network filesystems. By maintaining a cache of open file descriptors
|
|
Packit |
90a5c9 |
for commonly served files, httpd can avoid this delay. Currently httpd
|
|
Packit |
90a5c9 |
provides one implementation of File-Handle Caching.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
CacheFile
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The most basic form of caching present in httpd is the file-handle
|
|
Packit |
90a5c9 |
caching provided by mod_file_cache. Rather than caching
|
|
Packit |
90a5c9 |
file-contents, this cache maintains a table of open file descriptors. Files
|
|
Packit |
90a5c9 |
to be cached in this manner are specified in the configuration file using
|
|
Packit |
90a5c9 |
the CacheFile
|
|
Packit |
90a5c9 |
directive.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The
|
|
Packit |
90a5c9 |
CacheFile directive
|
|
Packit |
90a5c9 |
instructs httpd to open the file when it is started and to re-use
|
|
Packit |
90a5c9 |
this file-handle for all subsequent access to this file.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
CacheFile /usr/local/apache2/htdocs/index.html
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If you intend to cache a large number of files in this manner, you
|
|
Packit |
90a5c9 |
must ensure that your operating system's limit for the number of open
|
|
Packit |
90a5c9 |
files is set appropriately.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Although using CacheFile
|
|
Packit |
90a5c9 |
does not cause the file-contents to be cached per-se, it does mean
|
|
Packit |
90a5c9 |
that if the file changes while httpd is running these changes will
|
|
Packit |
90a5c9 |
not be picked up. The file will be consistently served as it was
|
|
Packit |
90a5c9 |
when httpd was started.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If the file is removed while httpd is running, it will continue
|
|
Packit |
90a5c9 |
to maintain an open file descriptor and serve the file as it was when
|
|
Packit |
90a5c9 |
httpd was started. This usually also means that although the file
|
|
Packit |
90a5c9 |
will have been deleted, and not show up on the filesystem, extra free
|
|
Packit |
90a5c9 |
space will not be recovered until httpd is stopped and the file
|
|
Packit |
90a5c9 |
descriptor closed.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Serving directly from system memory is universally the fastest method
|
|
Packit |
90a5c9 |
of serving content. Reading files from a disk controller or, even worse,
|
|
Packit |
90a5c9 |
from a remote network is orders of magnitude slower. Disk controllers
|
|
Packit |
90a5c9 |
usually involve physical processes, and network access is limited by
|
|
Packit |
90a5c9 |
your available bandwidth. Memory access on the other hand can take mere
|
|
Packit |
90a5c9 |
nano-seconds.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
System memory isn't cheap though, byte for byte it's by far the most
|
|
Packit |
90a5c9 |
expensive type of storage and it's important to ensure that it is used
|
|
Packit |
90a5c9 |
efficiently. By caching files in memory you decrease the amount of
|
|
Packit |
90a5c9 |
memory available on the system. As we'll see, in the case of operating
|
|
Packit |
90a5c9 |
system caching, this is not so much of an issue, but when using
|
|
Packit |
90a5c9 |
httpd's own in-memory caching it is important to make sure that you
|
|
Packit |
90a5c9 |
do not allocate too much memory to a cache. Otherwise the system
|
|
Packit |
90a5c9 |
will be forced to swap out memory, which will likely degrade
|
|
Packit |
90a5c9 |
performance.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Operating System Caching
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Almost all modern operating systems cache file-data in memory managed
|
|
Packit |
90a5c9 |
directly by the kernel. This is a powerful feature, and for the most
|
|
Packit |
90a5c9 |
part operating systems get it right. For example, on Linux, let's look at
|
|
Packit |
90a5c9 |
the difference in the time it takes to read a file for the first time
|
|
Packit |
90a5c9 |
and the second time;
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
colm@coroebus:~$ time cat testfile > /dev/null
|
|
Packit |
90a5c9 |
real 0m0.065s
|
|
Packit |
90a5c9 |
user 0m0.000s
|
|
Packit |
90a5c9 |
sys 0m0.001s
|
|
Packit |
90a5c9 |
colm@coroebus:~$ time cat testfile > /dev/null
|
|
Packit |
90a5c9 |
real 0m0.003s
|
|
Packit |
90a5c9 |
user 0m0.003s
|
|
Packit |
90a5c9 |
sys 0m0.000s
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Even for this small file, there is a huge difference in the amount
|
|
Packit |
90a5c9 |
of time it takes to read the file. This is because the kernel has cached
|
|
Packit |
90a5c9 |
the file contents in memory.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
By ensuring there is "spare" memory on your system, you can ensure
|
|
Packit |
90a5c9 |
that more and more file-contents will be stored in this cache. This
|
|
Packit |
90a5c9 |
can be a very efficient means of in-memory caching, and involves no
|
|
Packit |
90a5c9 |
extra configuration of httpd at all.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Additionally, because the operating system knows when files are
|
|
Packit |
90a5c9 |
deleted or modified, it can automatically remove file contents from the
|
|
Packit |
90a5c9 |
cache when necessary. This is a big advantage over httpd's in-memory
|
|
Packit |
90a5c9 |
caching which has no way of knowing when a file has changed.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Despite the performance and advantages of automatic operating system
|
|
Packit |
90a5c9 |
caching there are some circumstances in which in-memory caching may be
|
|
Packit |
90a5c9 |
better performed by httpd.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
MMapFile Caching
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
mod_file_cache provides the
|
|
Packit |
90a5c9 |
MMapFile directive, which
|
|
Packit |
90a5c9 |
allows you to have httpd map a static file's contents into memory at
|
|
Packit |
90a5c9 |
start time (using the mmap system call). httpd will use the in-memory
|
|
Packit |
90a5c9 |
contents for all subsequent accesses to this file.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
MMapFile /usr/local/apache2/htdocs/index.html
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
As with the
|
|
Packit |
90a5c9 |
CacheFile directive, any
|
|
Packit |
90a5c9 |
changes in these files will not be picked up by httpd after it has
|
|
Packit |
90a5c9 |
started.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The MMapFile
|
|
Packit |
90a5c9 |
directive does not keep track of how much memory it allocates, so
|
|
Packit |
90a5c9 |
you must ensure not to over-use the directive. Each httpd child
|
|
Packit |
90a5c9 |
process will replicate this memory, so it is critically important
|
|
Packit |
90a5c9 |
to ensure that the files mapped are not so large as to cause the
|
|
Packit |
90a5c9 |
system to swap memory.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Authorization and Access Control
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Using mod_cache in its default state where
|
|
Packit |
90a5c9 |
CacheQuickHandler is set to
|
|
Packit |
90a5c9 |
On is very much like having a caching reverse-proxy bolted
|
|
Packit |
90a5c9 |
to the front of the server. Requests will be served by the caching module
|
|
Packit |
90a5c9 |
unless it determines that the origin server should be queried just as an
|
|
Packit |
90a5c9 |
external cache would, and this drastically changes the security model of
|
|
Packit |
90a5c9 |
httpd.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
As traversing a filesystem hierarchy to examine potential
|
|
Packit |
90a5c9 |
.htaccess files would be a very expensive operation,
|
|
Packit |
90a5c9 |
partially defeating the point of caching (to speed up requests),
|
|
Packit |
90a5c9 |
mod_cache makes no decision about whether a cached
|
|
Packit |
90a5c9 |
entity is authorised for serving. In other words; if
|
|
Packit |
90a5c9 |
mod_cache has cached some content, it will be served
|
|
Packit |
90a5c9 |
from the cache as long as that content has not expired.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If, for example, your configuration permits access to a resource by IP
|
|
Packit |
90a5c9 |
address you should ensure that this content is not cached. You can do this
|
|
Packit |
90a5c9 |
by using the CacheDisable
|
|
Packit |
90a5c9 |
directive, or mod_expires. Left unchecked,
|
|
Packit |
90a5c9 |
mod_cache - very much like a reverse proxy - would cache
|
|
Packit |
90a5c9 |
the content when served and then serve it to any client, on any IP
|
|
Packit |
90a5c9 |
address.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
When the CacheQuickHandler
|
|
Packit |
90a5c9 |
directive is set to Off, the full set of request processing
|
|
Packit |
90a5c9 |
phases are executed and the security model remains unchanged.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Local exploits
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
As requests to end-users can be served from the cache, the cache
|
|
Packit |
90a5c9 |
itself can become a target for those wishing to deface or interfere with
|
|
Packit |
90a5c9 |
content. It is important to bear in mind that the cache must at all
|
|
Packit |
90a5c9 |
times be writable by the user which httpd is running as. This is in
|
|
Packit |
90a5c9 |
stark contrast to the usually recommended situation of maintaining
|
|
Packit |
90a5c9 |
all content unwritable by the Apache user.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
If the Apache user is compromised, for example through a flaw in
|
|
Packit |
90a5c9 |
a CGI process, it is possible that the cache may be targeted. When
|
|
Packit |
90a5c9 |
using mod_cache_disk, it is relatively easy to
|
|
Packit |
90a5c9 |
insert or modify a cached entity.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
This presents a somewhat elevated risk in comparison to the other
|
|
Packit |
90a5c9 |
types of attack it is possible to make as the Apache user. If you are
|
|
Packit |
90a5c9 |
using mod_cache_disk you should bear this in mind -
|
|
Packit |
90a5c9 |
ensure you upgrade httpd when security upgrades are announced and
|
|
Packit |
90a5c9 |
run CGI processes as a non-Apache user using suEXEC if possible.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Cache Poisoning
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
When running httpd as a caching proxy server, there is also the
|
|
Packit |
90a5c9 |
potential for so-called cache poisoning. Cache Poisoning is a broad
|
|
Packit |
90a5c9 |
term for attacks in which an attacker causes the proxy server to
|
|
Packit |
90a5c9 |
retrieve incorrect (and usually undesirable) content from the origin
|
|
Packit |
90a5c9 |
server.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
For example if the DNS servers used by your system running httpd
|
|
Packit |
90a5c9 |
are vulnerable to DNS cache poisoning, an attacker may be able to control
|
|
Packit |
90a5c9 |
where httpd connects to when requesting content from the origin server.
|
|
Packit |
90a5c9 |
Another example is so-called HTTP request-smuggling attacks.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
This document is not the correct place for an in-depth discussion
|
|
Packit |
90a5c9 |
of HTTP request smuggling (instead, try your favourite search engine)
|
|
Packit |
90a5c9 |
however it is important to be aware that it is possible to make
|
|
Packit |
90a5c9 |
a series of requests, and to exploit a vulnerability on an origin
|
|
Packit |
90a5c9 |
webserver such that the attacker can entirely control the content
|
|
Packit |
90a5c9 |
retrieved by the proxy.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Denial of Service / Cachebusting
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
The Vary mechanism allows multiple variants of the same URL to be
|
|
Packit |
90a5c9 |
cached side by side. Depending on header values provided by the client,
|
|
Packit |
90a5c9 |
the cache will select the correct variant to return to the client. This
|
|
Packit |
90a5c9 |
mechanism can become a problem when an attempt is made to vary on a
|
|
Packit |
90a5c9 |
header that is known to contain a wide range of possible values under
|
|
Packit |
90a5c9 |
normal use, for example the User-Agent header. Depending
|
|
Packit |
90a5c9 |
on the popularity of the particular web site thousands or millions of
|
|
Packit |
90a5c9 |
duplicate cache entries could be created for the same URL, crowding
|
|
Packit |
90a5c9 |
out other entries in the cache.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
In other cases, there may be a need to change the URL of a particular
|
|
Packit |
90a5c9 |
resource on every request, usually by adding a "cachebuster" string to
|
|
Packit |
90a5c9 |
the URL. If this content is declared cacheable by a server for a
|
|
Packit |
90a5c9 |
significant freshness lifetime, these entries can crowd out
|
|
Packit |
90a5c9 |
legitimate entries in a cache. While mod_cache
|
|
Packit |
90a5c9 |
provides a
|
|
Packit |
90a5c9 |
CacheIgnoreURLSessionIdentifiers
|
|
Packit |
90a5c9 |
directive, this directive should be used with care to ensure that
|
|
Packit |
90a5c9 |
downstream proxy or browser caches aren't subjected to the same denial
|
|
Packit |
90a5c9 |
of service issue.
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
|
|
Packit |
90a5c9 |
Available Languages: en |
|
|
Packit |
90a5c9 |
fr |
|
|
Packit |
90a5c9 |
tr
|
|
Packit |
90a5c9 |
Notice:This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
|
|
Packit |
90a5c9 |
<script type="text/javascript">
|
|
Packit |
90a5c9 |
var comments_shortname = 'httpd';
|
|
Packit |
90a5c9 |
var comments_identifier = 'http://httpd.apache.org/docs/2.4/caching.html';
|
|
Packit |
90a5c9 |
(function(w, d) {
|
|
Packit |
90a5c9 |
if (w.location.hostname.toLowerCase() == "httpd.apache.org") {
|
|
Packit |
90a5c9 |
d.write('
|
|
Packit |
90a5c9 |
var s = d.createElement('script');
|
|
Packit |
90a5c9 |
s.type = 'text/javascript';
|
|
Packit |
90a5c9 |
s.async = true;
|
|
Packit |
90a5c9 |
s.src = 'https://comments.apache.org/show_comments.lua?site=' + comments_shortname + '&page=' + comments_identifier;
|
|
Packit |
90a5c9 |
(d.getElementsByTagName('head')[0] || d.getElementsByTagName('body')[0]).appendChild(s);
|
|
Packit |
90a5c9 |
}
|
|
Packit |
90a5c9 |
else {
|
|
Packit |
90a5c9 |
d.write('
|
|
Packit |
90a5c9 |
}
|
|
Packit |
90a5c9 |
})(window, document);
|
|
Packit |
90a5c9 |
//--></script>
|
|
Packit |
90a5c9 |
Copyright 2018 The Apache Software Foundation.
Licensed under the Apache License, Version 2.0.
|
|
Packit |
90a5c9 |
Modules | Directives | FAQ | Glossary | Sitemap <script type="text/javascript">
|
|
Packit |
90a5c9 |
if (typeof(prettyPrint) !== 'undefined') {
|
|
Packit |
90a5c9 |
prettyPrint();
|
|
Packit |
90a5c9 |
}
|
|
Packit |
90a5c9 |
//--></script>
|
|
Packit |
90a5c9 |
</body></html>
|
