defaults.bad_request(request, exception, template_name='400.html') When a SuspiciousOperation is raised in Django, it may be handled by a component of Django (for example resetting the session data). If not specifically handled, Django will consider the current request a ‘bad request’ instead of a server error. django.views.defaults.bad_request, is otherwise very similar to the server_error view, but returns with the status code 400 indicating that the error condition was the result of a cli

defaults.page_not_found(request, exception, template_name='404.html') When you raise Http404 from within a view, Django loads a special view devoted to handling 404 errors. By default, it’s the view django.views.defaults.page_not_found(), which either produces a very simple “Not Found” message or loads and renders the template 404.html if you created it in your root template directory. The default 404 view will pass two variables to the template: request_path, which is the URL that resulted

defaults.permission_denied(request, exception, template_name='403.html') In the same vein as the 404 and 500 views, Django has a view to handle 403 Forbidden errors. If a view results in a 403 exception then Django will, by default, call the view django.views.defaults.permission_denied. This view loads and renders the template 403.html in your root template directory, or if this file does not exist, instead serves the text “403 Forbidden”, as per RFC 7231#section-6.5.3 (the HTTP 1.1 Specific

defaults.server_error(request, template_name='500.html') Similarly, Django executes special-case behavior in the case of runtime errors in view code. If a view results in an exception, Django will, by default, call the view django.views.defaults.server_error, which either produces a very simple “Server Error” message or loads and renders the template 500.html if you created it in your root template directory. The default 500 view passes no variables to the 500.html template and is rendered w

class django.views.generic.base.ContextMixin Methods get_context_data(**kwargs) Returns a dictionary representing the template context. The keyword arguments provided will make up the returned context. Example usage: def get_context_data(self, **kwargs): context = super(RandomNumberView, self).get_context_data(**kwargs) context['number'] = random.randrange(1, 100) return context The template context of all class-based generic views include a view variable that points to the V

get_context_data(**kwargs) Returns a dictionary representing the template context. The keyword arguments provided will make up the returned context. Example usage: def get_context_data(self, **kwargs): context = super(RandomNumberView, self).get_context_data(**kwargs) context['number'] = random.randrange(1, 100) return context The template context of all class-based generic views include a view variable that points to the View instance. Use alters_data where appropriate Note th

class django.views.generic.base.RedirectView Redirects to a given URL. The given URL may contain dictionary-style string formatting, which will be interpolated against the parameters captured in the URL. Because keyword interpolation is always done (even if no arguments are passed in), any "%" characters in the URL must be written as "%%" so that Python will convert them to a single percent sign on output. If the given URL is None, Django will return an HttpResponseGone (410). Ancestors (MRO

get_redirect_url(*args, **kwargs) Constructs the target URL for redirection. The default implementation uses url as a starting string and performs expansion of % named parameters in that string using the named groups captured in the URL. If url is not set, get_redirect_url() tries to reverse the pattern_name using what was captured in the URL (both named and unnamed groups are used). If requested by query_string, it will also append the query string to the generated URL. Subclasses may imple

pattern_name The name of the URL pattern to redirect to. Reversing will be done using the same args and kwargs as are passed in for this view.

permanent Whether the redirect should be permanent. The only difference here is the HTTP status code returned. If True, then the redirect will use status code 301. If False, then the redirect will use status code 302. By default, permanent is False. Changed in Django 1.9: The default value of the permanent attribute changed from True to False.