patch_response_headers(response, cache_timeout=None) [source] Adds some useful headers to the given HttpResponse object: ETag Last-Modified Expires Cache-Control Each header is only added if it isn’t already set. cache_timeout is in seconds. The CACHE_MIDDLEWARE_SECONDS setting is used by default.

patch_cache_control(response, **kwargs) [source] This function patches the Cache-Control header by adding all keyword arguments to it. The transformation is as follows: All keyword parameter names are turned to lowercase, and underscores are converted to hyphens. If the value of a parameter is True (exactly True, not just a true value), only the parameter name is added to the header. All other parameters are added with their value, after applying str() to it.

add_never_cache_headers(response) [source] Adds a Cache-Control: max-age=0, no-cache, no-store, must-revalidate header to a response to indicate that a page should never be cached. Changed in Django 1.8.8: In older versions, Cache-Control: max-age=0 was sent. This didn’t reliably prevent caching in all browsers.

get_cache_key(request, key_prefix=None) [source] Returns a cache key based on the request path. It can be used in the request phase because it pulls the list of headers to take into account from the global path registry and uses those to build a cache key to check against. If there is no headerlist stored, the page needs to be rebuilt, so this function returns None.

learn_cache_key(request, response, cache_timeout=None, key_prefix=None) [source] Learns what headers to take into account for some request path from the response object. It stores those headers in a global path registry so that later access to that path will know what headers to take into account without building the response object itself. The headers are named in the Vary header of the response, but we want to prevent response generation. The list of headers to use for cache key generation

get_max_age(response) [source] Returns the max-age from the response Cache-Control header as an integer (or None if it wasn’t found or wasn’t an integer).

Caution This is an advanced topic. A working knowledge of Django’s class-based views is advised before exploring these techniques. Django’s built-in class-based views provide a lot of functionality, but some of it you may want to use separately. For instance, you may want to write a view that renders a template to make the HTTP response, but you can’t use TemplateView; perhaps you need to render a template only on POST, with GET doing something else entirely. While you could use TemplateRespo

Introductions to all the key parts of Django you’ll need to know: How to install Django Models and databases Handling HTTP requests Working with forms Templates Class-based views Migrations Managing files Testing in Django User authentication in Django Django’s cache framework Conditional View Processing Cryptographic signing Sending email Internationalization and localization Logging Pagination Porting to Python 3 Security in Django Performance and optimization Serializing Django objects Djang

Django comes with a user authentication system. It handles user accounts, groups, permissions and cookie-based user sessions. This section of the documentation explains how the default implementation works out of the box, as well as how to extend and customize it to suit your project’s needs. Overview The Django authentication system handles both authentication and authorization. Briefly, authentication verifies a user is who they claim to be, and authorization determines what an authenticated

url_name The name of the URL pattern that matches the URL.