  
      The cache is keyed by the URL and some data from the headers.
      Additionally there is the key prefix that is used to distinguish different
      cache areas in a multi-site setup. You could use the
      sites.get_current().domain, for example, as that is unique across a Django
      project.
  
      Additionally, all headers from the response's Vary header will be taken
      into account on caching -- just like the middleware does.
      """
 
</s> remove       from django.conf import settings
 </s> add       from django.contrib.sites.models import get_current_site </s> remove For code which relies on getting the current domain but cannot be certain
that the sites framework will be installed for any given project, there is a
utility function :func:`~django.contrib.sites.models.get_current_site` that
takes a request object as an argument and returns either a Site instance (if
the sites framework is installed) or a RequestSite instance (if it is not).
This allows loose coupling with the sites framework and provides a usable
fallback for cases where it is not installed.

.. function:: get_current_site(request)

    Checks if contrib.sites is installed and returns either the current
    :class:`~django.contrib.sites.models.Site` object or a
    :class:`~django.contrib.sites.models.RequestSite` object based on
    the request.

 </s> add  </s> remove   for a redirect, it takes into account the current :setting:`SITE_ID`.
 </s> add   for a redirect, it takes into account the current site. </s> remove The idiom of retrieving the :class:`~django.contrib.sites.models.Site` object
for the value of :setting:`settings.SITE_ID <SITE_ID>` is quite common, so
the :class:`~django.contrib.sites.models.Site` model's manager has a
``get_current()`` method. This example is equivalent to the previous one::
 </s> add This has also the advantage of checking if the sites framework is installed, and
return a :class:`RequestSite` instance if it is not.

If you don't have access to the request object, you can use the
``get_current()`` method of the :class:`~django.contrib.sites.models.Site`
model's manager. You should then ensure that your settings file does contain
the :setting:`SITE_ID` setting. This example is equivalent to the previous one:: </s> remove   :class:`~django.contrib.sites.models.Site` is set to the current
  :setting:`SITE_ID`, and when comments are listed via the appropriate
  template tag, only the comments for the current site are displayed.
 </s> add   :class:`~django.contrib.sites.models.Site` is set to the current site,
  and when comments are listed via the appropriate template tag, only the
  comments for the current site are displayed.
    sites.get_current_site().domain, for example, as that is unique across a Django
  
      The cache is keyed by the URL and some data from the headers.
      Additionally there is the key prefix that is used to distinguish different
      cache areas in a multi-site setup. You could use the
    sites.get_current_site().domain, for example, as that is unique across a Django
      project.
  
      Additionally, all headers from the response's Vary header will be taken
      into account on caching -- just like the middleware does.
      """
keep keep keep keep replace keep keep keep keep keep
 Made more extensive use of get_current_site

Refs #15089 
django/views/decorators/cache.py