mirrors/django
mirrors/django
0
0
Fork 0
mirror of https://github.com/django/django.git synced 2024-12-01 15:42:04 +01:00
Code Issues Releases Wiki Activity

Fixed #22247 -- Replaced "upstream" with "downstream" in cache docs.

Browse Source 
Thanks valgarv at gmx.net for the report.
This commit is contained in:
Tim Graham 2014-03-24 09:15:32 -04:00
parent eed7e1d4f6
commit 60d2dde286
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
docs/topics/cache.txt
View File

@ -34,7 +34,7 @@ offers different levels of cache granularity: You can cache the output of
specific views, you can cache only the pieces that are difficult to produce,
or you can cache your entire site.
Django also works well with "upstream" caches, such as `Squid
Django also works well with "downstream" caches, such as `Squid
<http://www.squid-cache.org>`_ and browser-based caches. These are the types of
caches that you don't directly control but to which you can provide hints (via
HTTP headers) about which parts of your site should be cached, and how.
@ -1002,15 +1002,15 @@ instance, to do this for the ``locmem`` backend, put this code in a module::
...and use the dotted Python path to this class in the
:setting:`BACKEND <CACHES-BACKEND>` portion of your :setting:`CACHES` setting.
Upstream caches
===============
Downstream caches
=================
So far, this document has focused on caching your *own* data. But another type
of caching is relevant to Web development, too: caching performed by "upstream"
caches. These are systems that cache pages for users even before the request
reaches your Web site.
of caching is relevant to Web development, too: caching performed by
"downstream" caches. These are systems that cache pages for users even before
the request reaches your Web site.
Here are a few examples of upstream caches:
Here are a few examples of downstream caches:
* Your ISP may cache certain pages, so if you requested a page from
http://example.com/, your ISP would send you the page without having to
@ -1028,7 +1028,7 @@ Here are a few examples of upstream caches:
subsequent requests to that page, without even contacting the Web page
again to see whether it has changed.
Upstream caching is a nice efficiency boost, but there's a danger to it:
Downstream caching is a nice efficiency boost, but there's a danger to it:
Many Web pages' contents differ based on authentication and a host of other
variables, and cache systems that blindly save pages based purely on URLs could
expose incorrect or sensitive data to subsequent visitors to those pages.
@ -1040,7 +1040,7 @@ their user-specific inbox page cached for subsequent visitors to the site.
That's not cool.
Fortunately, HTTP provides a solution to this problem. A number of HTTP headers
exist to instruct upstream caches to differ their cache contents depending on
exist to instruct downstream caches to differ their cache contents depending on
designated variables, and to tell caching mechanisms not to cache particular
pages. We'll look at some of these headers in the sections that follow.
@ -1092,7 +1092,7 @@ You can pass multiple headers to ``vary_on_headers()``::
def my_view(request):
# ...
This tells upstream caches to vary on *both*, which means each combination of
This tells downstream caches to vary on *both*, which means each combination of
user-agent and cookie will get its own cache value. For example, a request with
the user-agent ``Mozilla`` and the cookie value ``foo=bar`` will be considered
different from a request with the user-agent ``Mozilla`` and the cookie value