A few doc additions for changes from d228c119.

See :ref:`including-other-urlconfs` and :ref:`namespaces-and-include`.

handler400

----------

.. data:: handler400

.. versionadded:: 1.6

A callable, or a string representing the full Python import path to the view

that should be called if the HTTP client has sent a request that caused an error

condition and a response with a status code of 400.

By default, this is ``'django.views.defaults.permission_denied'``. That default

value should suffice.

See the documentation about :ref:`the 400 (bad request) view

<http_bad_request_view>` for more information.

handler403

----------

When Django can't find a regex matching the requested URL, or when an

exception is raised, Django will invoke an error-handling view.

The views to use for these cases are specified by three variables. Their

The views to use for these cases are specified by four variables. Their

default values should suffice for most projects, but further customization is

possible by assigning values to them.

* ``handler404`` -- See :data:`django.conf.urls.handler404`.

* ``handler500`` -- See :data:`django.conf.urls.handler500`.

* ``handler403`` -- See :data:`django.conf.urls.handler403`.

* ``handler400`` -- See :data:`django.conf.urls.handler400`.

.. _urlpatterns-view-prefix:

which is the URL that resulted in the error.

The ``page_not_found`` view should suffice for 99% of Web applications, but if

you want to override it, you can specify ``handler404`` in your root URLconf

(setting ``handler404`` anywhere else will have no effect), like so::

you want to override it, you can specify :data:`~django.conf.urls.handler404`

in your root URLconf (setting ``handler404`` anywhere else will have no

effect), like so::

    handler404 = 'mysite.views.my_custom_404_view'

The 500 (server error) view

----------------------------

.. function:: django.views.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

rendered with an empty ``Context`` to lessen the chance of additional errors.

This ``server_error`` view should suffice for 99% of Web applications, but if

you want to override the view, you can specify ``handler500`` in your URLconf,

like so::

you want to override the view, you can specify

:data:`~django.conf.urls.handler500` in your root URLconf, like so::

    handler500 = 'mysite.views.my_custom_error_view'

The 403 (HTTP Forbidden) view

-----------------------------

.. function:: django.views.defaults.permission_denied(request, 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``.

        # ...

It is possible to override ``django.views.defaults.permission_denied`` in the

same way you can for the 404 and 500 views by specifying a ``handler403`` in

your URLconf::

same way you can for the 404 and 500 views by specifying a

:data:`~django.conf.urls.handler403` in your root URLconf::

    handler403 = 'mysite.views.my_custom_permission_denied_view'

The 400 (bad request) view

--------------------------

.. versionadded:: 1.6

.. function:: django.views.defaults.bad_request(request, template_name='400.html')

When a :exc:`~django.core.exceptions.SuspiciousOperation` is raised in Django,

the 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.

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.

The view ``django.views.defaults.bad_request``, is otherwise very similar to

the ``server_error`` view, but returns with the status code 400 indicating that

``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.

Like the ``server_error`` view, the default ``bad_request`` should suffice for

Like ``server_error``, the default ``bad_request`` should suffice for

99% of Web applications, but if you want to override the view, you can specify

``handler400`` in your URLconf, like so::

:data:`~django.conf.urls.handler400` in your root URLconf, like so::

    handler400 = 'mysite.views.my_custom_bad_request_view'