diff --git a/docs/ref/contrib/csrf.txt b/docs/ref/contrib/csrf.txt
index 8dc1373..80aefb1 100644
|
a
|
b
|
methods are assumed to be unsafe, for maximum protection.
|
| 227 | 227 | Caching |
| 228 | 228 | ======= |
| 229 | 229 | |
| | 230 | |
| | 231 | |
| | 232 | |
| | 233 | |
| | 234 | |
| | 235 | |
| 230 | 236 | If the :ttag:`csrf_token` template tag is used by a template (or the |
| 231 | 237 | ``get_token`` function is called some other way), ``CsrfViewMiddleware`` will |
| 232 | 238 | add a cookie and a ``Vary: Cookie`` header to the response. This means that the |
| 233 | 239 | middleware will play well with the cache middleware if it is used as instructed |
| 234 | 240 | (``UpdateCacheMiddleware`` goes before all other middleware). |
| 235 | 241 | |
| 236 | | However, if you use cache decorators on individual views, the CSRF middleware |
| 237 | | will not yet have been able to set the Vary header. In this case, on any views |
| 238 | | that will require a CSRF token to be inserted you should use the |
| 239 | | :func:`django.views.decorators.vary.vary_on_cookie` decorator first:: |
| 240 | | |
| 241 | | from django.views.decorators.cache import cache_page |
| 242 | | from django.views.decorators.vary import vary_on_cookie |
| 243 | | |
| 244 | | @cache_page(60 * 15) |
| 245 | | @vary_on_cookie |
| 246 | | def my_view(request): |
| 247 | | # ... |
| | 242 | :ref:`Per-view caching <cache-per-view>` is not compatible with the :ttag:`csrf_token` template tag, as |
| | 243 | the entire view (including the CSRF token in your template) will be cached and |
| | 244 | sent upon subsequent request. |
| 248 | 245 | |
| 249 | 246 | |
| 250 | 247 | Testing |
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
index 0dbe844..2281a3e 100644
|
a
|
b
|
language.
|
| 491 | 491 | |
| 492 | 492 | __ `Controlling cache: Using other headers`_ |
| 493 | 493 | |
| | 494 | |
| | 495 | |
| 494 | 496 | The per-view cache |
| 495 | 497 | ================== |
| 496 | 498 | |