diff --git a/docs/ref/contrib/csrf.txt b/docs/ref/contrib/csrf.txt
index 8dc1373..80aefb1 100644
--- a/docs/ref/contrib/csrf.txt
+++ b/docs/ref/contrib/csrf.txt
@@ -227,24 +227,21 @@ methods are assumed to be unsafe, for maximum protection.
 Caching
 =======
 
+.. admonition:: Caching and CSRF don't mix well
+
+    Mixing CSRF protection and caching is inherently tricky. You have to make
+    sure that you aren't caching the CSRF token, which can lead to subtle
+    bugs.
+
 If the :ttag:`csrf_token` template tag is used by a template (or the
 ``get_token`` function is called some other way), ``CsrfViewMiddleware`` will
 add a cookie and a ``Vary: Cookie`` header to the response. This means that the
 middleware will play well with the cache middleware if it is used as instructed
 (``UpdateCacheMiddleware`` goes before all other middleware).
 
-However, if you use cache decorators on individual views, the CSRF middleware
-will not yet have been able to set the Vary header.  In this case, on any views
-that will require a CSRF token to be inserted you should use the
-:func:`django.views.decorators.vary.vary_on_cookie` decorator first::
-
-  from django.views.decorators.cache import cache_page
-  from django.views.decorators.vary import vary_on_cookie
-
-  @cache_page(60 * 15)
-  @vary_on_cookie
-  def my_view(request):
-      # ...
+:ref:`Per-view caching <cache-per-view>` is not compatible with the :ttag:`csrf_token` template tag, as
+the entire view (including the CSRF token in your template) will be cached and 
+sent upon subsequent request.
 
 
 Testing
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
index 0dbe844..2281a3e 100644
--- a/docs/topics/cache.txt
+++ b/docs/topics/cache.txt
@@ -491,6 +491,8 @@ language.
 
 __ `Controlling cache: Using other headers`_
 
+.. _cache-per-view:
+
 The per-view cache
 ==================