mirror of
https://github.com/django/django.git
synced 2024-12-25 02:26:12 +00:00
[1.7.x] Fixed #22247 -- Replaced "upstream" with "downstream" in cache docs.
Thanks valgarv at gmx.net for the report.
Backport of 60d2dde286
from master
This commit is contained in:
parent
68a80166cd
commit
57a373b08c
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user