diff --git a/docs/manual/caching.html.en b/docs/manual/caching.html.en index fd4c5caaf4..6d4f835f7d 100644 --- a/docs/manual/caching.html.en +++ b/docs/manual/caching.html.en @@ -297,6 +297,31 @@ Vary: negotiate,accept-language,accept-charset
Using mod_cache is very much like having a built
+ in reverse-proxy. Requests will be served by the caching module unless
+ it determines that the backend should be queried. When caching local
+ resources, this drastically changes the security model of Apache.
As traversing a filesystem hierarchy to examine potential
+ .htaccess files would be a very expensive operation,
+ partially defeating the point of caching (to speed up requests),
+ mod_cache makes no decision about whether a cached
+ entity is authorised for serving. In other words; if
+ mod_cache has cached some content, it will be served
+ from the cache as long as that content has not expired.
If, for example, your configuration permits access to a resource by IP
+ address you should ensure that this content is not cached. You can do this by
+ using the CacheDisable
+ directive, or mod_expires. Left unchecked,
+ mod_cache - very much like a reverse proxy - would cache
+ the content when served and then serve it to any client, on any IP
+ address.
Allow and Deny directives. You
+ should not enable caching for any content to which you wish
+ to limit access by client host name, address or environment
+ variable.mod_cache implements an RFC 2616 compliant HTTP
content cache that can be used to cache either local or proxied content.
mod_cache requires the services of one or more storage
diff --git a/docs/manual/mod/mod_cache.xml.ja b/docs/manual/mod/mod_cache.xml.ja
index 599cd6e2fa..a55d3a2fb7 100644
--- a/docs/manual/mod/mod_cache.xml.ja
+++ b/docs/manual/mod/mod_cache.xml.ja
@@ -1,7 +1,7 @@
-
+
+
+
+
+
+
+
+