summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorLincolnPuzey <18750802+LincolnPuzey@users.noreply.github.com>2026-02-26 03:55:21 +0800
committerGitHub <noreply@github.com>2026-02-25 14:55:21 -0500
commit4aefc9ea51cc2d78f43b1dc2aa69732e55d18a56 (patch)
tree8f58db94a7415043b063a4d5c0592d474ee01ce8 /docs
parent497d9cdc67f0bdae929fcde677b5f441e94a6c8b (diff)
Fixed #36848 -- Mentioned BadRequest exception in docs/ref/views.txt.
Diffstat (limited to 'docs')
-rw-r--r--docs/ref/views.txt22
1 files changed, 13 insertions, 9 deletions
diff --git a/docs/ref/views.txt b/docs/ref/views.txt
index b60ffc2ed8..d7ad83a64a 100644
--- a/docs/ref/views.txt
+++ b/docs/ref/views.txt
@@ -148,16 +148,20 @@ The 400 (bad request) view
.. function:: defaults.bad_request(request, exception, template_name='400.html')
-When a :exc:`~django.core.exceptions.SuspiciousOperation` is raised in Django,
+Similarly, Django has a view to handle 400 Bad Request errors.
+
+This view either produces a "Bad Request" message or loads and renders the
+template ``400.html`` if you created it in your root template directory.
+It returns with status code 400 indicating that the error condition was the
+result of a client operation. By default, nothing related to the exception that
+triggered the view is passed to the template context, as the exception message
+might contain sensitive information like filesystem paths.
+
+``django.views.defaults.bad_request`` is triggered by a
+:exc:`~django.core.exceptions.BadRequest` exception. Also, when a
+:exc:`~django.core.exceptions.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 client operation. By default, nothing
-related to the exception that triggered the view is passed to the template
-context, as the exception message might contain sensitive information like
-filesystem paths.
+'bad request' instead of a server error, and handle it with ``bad_request``.
``bad_request`` views are also only used when :setting:`DEBUG` is ``False``.