Talking about Cache Control in Python Django framework

This article mainly introduces the Cache Control in the Python Django framework, including the use of headers other than the Vary header, for more information about cache, see the privacy of data and the storage of data in cascading cache.

Generally, a user will face two types of cache: his or her own browser cache (Private cache) and his or her provider cache (Public cache ). The public cache is used by multiple users and controlled by others. This leads to the issue of sensitive data that you don't want to encounter. For example, your bank account is stored in the public cache. Therefore, Web applications need to tell the cached data in a certain way that is private and public.

The solution is to indicate that a page cache should be private. To do this in Django, you can use the cache_control view modifier, for example:

from django.views.decorators.cache import cache_control@cache_control(private=True)def my_view(request):  # ...

The modifier is responsible for sending the corresponding HTTP header in the background.

There are other ways to control cache parameters. For example, HTTP allows an application to perform the following operations:

• Defines the maximum time that a page can be cached.
• Specify whether a cache always checks for newer versions. The cached content is transmitted only when there is no update. (Some caches still transmit the cached content even when the server page changes, because the cached copy has not expired .)

In Django, you can use the cache_control view modifier to specify these cache parameters. In this example, cache_control tells the cache to re-verify the cache for each access and save the cached version within 3600 seconds:

from django.views.decorators.cache import cache_control@cache_control(must_revalidate=True, max_age=3600)def my_view(request):  # ...

In cache_control (), any valid Cache-Control HTTP command is valid. The complete list is shown below:

  public=True  private=True  no_cache=True  no_transform=True  must_revalidate=True  proxy_revalidate=True  max_age=num_seconds  s_maxage=num_seconds

Cache middleware has used CACHE_MIDDLEWARE_SETTINGS to set the cache header max-age. If you use a custom max_age in the cache_control modifier, the modifier obtains priority and the value of this header is correctly merged.

If you want to use the header to completely disable caching, the django. views. decorators. cache. never_cache decorator Can add header information to ensure that the response is not cached. For example:

from django.views.decorators.cache import never_cache@never_cachedef myview(request):  # ...

Other Optimizations

Django has some other middleware to help you optimize the application performance:

• Django. middleware. http. ConditionalGetMiddleware adds conditional support for GET response based on ETag and Last-Modified headers for modern browsers.
• Django.middleware.gzip. GZipMiddleware compresses the response content for all modern browsers to save bandwidth and time.

MIDDLEWARE_CLASSES Sequence

If cache middleware is used, make sure that the configuration is correct in the MIDDLEWARE_CLASSES settings. Because cache middleware needs to know which header information is differentiated by which cache regions. Middleware always tries its best to add information in the Vary response header.

UpdateCacheMiddleware runs in the corresponding phase. Because the middleware runs in reverse order, the middleware at the top of all lists runs at the end of the corresponding stage. All, you need to ensure that UpdateCacheMiddleware is placed before any middleware that may add information to the Vary header. The following middleware module is like this:

• SessionMiddleware for adding cookies
• Add GZipMiddleware for Accept-Encoding
• Add LocaleMiddleware for Accept-Language

On the other hand, FetchFromCacheMiddleware runs in the request phase, and the middleware is executed sequentially, so the project at the top of the list will be executed first. FetchFromCacheMiddleware also needs to run after the middleware of the Vary header is modified, so FetchFromCacheMiddleware must be placed behind them.