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

Thanks valgarv at gmx.net for the report.

docs/topics/cache.txt

@@ -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