View decoratorsLink to this heading

Django provides several decorators that can be applied to views to support various HTTP features.

See Decorating the class for how to use these decorators with class-based views.

Allowed HTTP methodsLink to this heading

The decorators in django.views.decorators.http can be used to restrict access to views based on the request method. These decorators will return a django.http.HttpResponseNotAllowed if the conditions are not met.

require_http_methods(request_method_list)Link to this definition

Decorator to require that a view only accepts particular request methods. Usage:

Code
from django.views.decorators.http import require_http_methods

@require_http_methods(["GET", "POST"])
def my_view(request):
    # I can assume now that only GET or POST requests make it this far
    # ...
    pass

Note that request methods should be in uppercase.

require_GET()Link to this definition

Decorator to require that a view only accepts the GET method.

require_POST()Link to this definition

Decorator to require that a view only accepts the POST method.

require_safe()Link to this definition

Decorator to require that a view only accepts the GET and HEAD methods. These methods are commonly considered «safe» because they should not have the significance of taking an action other than retrieving the requested resource.

Conditional view processingLink to this heading

The following decorators in django.views.decorators.http can be used to control caching behavior on particular views.

condition(etag_func=None, last_modified_func=None)Link to this definition
etag(etag_func)Link to this definition
last_modified(last_modified_func)Link to this definition

These decorators can be used to generate ETag and Last-Modified headers; see conditional view processing.

GZip compressionLink to this heading

The decorators in django.views.decorators.gzip control content compression on a per-view basis.

gzip_page()Link to this definition

This decorator compresses content if the browser allows gzip compression. It sets the Vary header accordingly, so that caches will base their storage on the Accept-Encoding header.

Vary headersLink to this heading

The decorators in django.views.decorators.vary can be used to control caching based on specific request headers.

vary_on_headers(*headers)Link to this definition

The Vary header defines which request headers a cache mechanism should take into account when building its cache key.

See using vary headers.

CachingLink to this heading

The decorators in django.views.decorators.cache control server and client-side caching.

cache_control(**kwargs)Link to this definition

This decorator patches the response’s Cache-Control header by adding all of the keyword arguments to it. See patch_cache_control() for the details of the transformation.

never_cache(view_func)Link to this definition

This decorator adds an Expires header to the current date/time.

This decorator adds a Cache-Control: max-age=0, no-cache, no-store, must-revalidate, private header to a response to indicate that a page should never be cached.

Each header is only added if it isn’t already set.

CommonLink to this heading

The decorators in django.views.decorators.common allow per-view customization of CommonMiddleware behavior.

no_append_slash()Link to this definition

This decorator allows individual views to be excluded from APPEND_SLASH URL normalization.