Fixed #18807 -- Made 404.html and 500.html optional

from django import http

from django.template import (Context, RequestContext,

                             loader, TemplateDoesNotExist)

                             loader, Template, TemplateDoesNotExist)

from django.views.decorators.csrf import requires_csrf_token

        request_path

            The path of the requested URL (e.g., '/app/pages/bad_page/')

    """

    t = loader.get_template(template_name) # You need to create a 404.html template.

    return http.HttpResponseNotFound(t.render(RequestContext(request, {'request_path': request.path})))

    try:

        template = loader.get_template(template_name)

    except TemplateDoesNotExist:

        template = Template(

            '<h1>Not Found</h1>'

            '<p>The requested URL {{ request_path }} was not found on this server.</p>')

    return http.HttpResponseNotFound(template.render(RequestContext(request, {'request_path': request.path})))

@requires_csrf_token

    Templates: :template:`500.html`

    Context: None

    """

    t = loader.get_template(template_name) # You need to create a 500.html template.

    return http.HttpResponseServerError(t.render(Context({})))

    try:

        template = loader.get_template(template_name)

    except TemplateDoesNotExist:

        return http.HttpResponseServerError('<h1>Server Error (500)</h1>')

    return http.HttpResponseServerError(template.render(Context({})))

# This can be called when CsrfViewMiddleware.process_view has not run,

You normally won't have to bother with writing 404 views. If you don't set

``handler404``, the built-in view :func:`django.views.defaults.page_not_found`

is used by default. In this case, you still have one obligation: create a

``404.html`` template in the root of your template directory. The default 404

view will use that template for all 404 errors. If :setting:`DEBUG` is set to

``False`` (in your settings module) and if you didn't create a ``404.html``

file, an ``Http500`` is raised instead. So remember to create a ``404.html``.

is used by default. Optionally, you can create a ``404.html`` template

in the root of your template directory. The default 404 view will then use that

template for all 404 errors when :setting:`DEBUG` is set to ``False`` (in your

settings module).

A couple more things to note about 404 views:

    :class:`~django.contrib.flatpages.middleware.FlatpageFallbackMiddleware`

    only steps in once another view has successfully produced a 404 response.

    If another view or middleware class attempts to produce a 404 but ends up

    raising an exception instead (such as a ``TemplateDoesNotExist``

    exception if your site does not have an appropriate template to

    use for HTTP 404 responses), the response will become an HTTP 500

    raising an exception instead, the response will become an HTTP 500

    ("Internal Server Error") and the

    :class:`~django.contrib.flatpages.middleware.FlatpageFallbackMiddleware`

    will not attempt to serve a flat page.

  look up permissions by using ``{% if 'someapp.someperm' in perms %}``

  in templates.

* It's not required any more to have ``404.html`` and ``500.html`` templates in

  the root templates directory. Django will output some basic error messages for

  both situations when those templates are not found. Of course, it's still

  recommended as good practice to provide those templates in order to present

  pretty error pages to the user.

Backwards incompatible changes in 1.5

=====================================

When you raise an ``Http404`` exception, Django loads a special view devoted

to handling 404 errors. By default, it's the view

``django.views.defaults.page_not_found``, which loads and renders the template

``404.html``.

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

This means you need to define a ``404.html`` template in your root template

directory. This template will be used for all 404 errors. The default 404 view

will pass one variable to the template: ``request_path``, which is the URL

that resulted in the error.

The default 404 view will pass one variable to the template: ``request_path``,

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 URLconf, like

``handler404`` in your root URLconf, and falling back to

``django.views.defaults.page_not_found`` if you did not define one.

Four things to note about 404 views:

Three things to note about 404 views:

* The 404 view is also called if Django doesn't find a match after

  checking every regular expression in the URLconf.

* If you don't define your own 404 view — and simply use the default,

  which is recommended — you still have one obligation: you must create a

  ``404.html`` template in the root of your template directory.

* The 404 view is passed a :class:`~django.template.RequestContext` and

  will have access to variables supplied by your

  :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting (e.g., ``MEDIA_URL``).

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 loads and renders the

template ``500.html``.

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.

This means you need to define a ``500.html`` template in your root template

directory. This template will be used for all server errors. The default 500

view passes no variables to this template and is rendered with an empty

``Context`` to lessen the chance of additional errors.

The default 500 view passes no variables to the ``500.html`` template and is

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,

``handler500`` in your root URLconf, and falling back to

``django.views.defaults.server_error`` if you did not define one.

Two things to note about 500 views:

* If you don't define your own 500 view — and simply use the default,

  which is recommended — you still have one obligation: you must create a

  ``500.html`` template in the root of your template directory.

One thing to note about 500 views:

* If :setting:`DEBUG` is set to ``True`` (in your settings module), then

  your 500 view will never be used, and the traceback will be displayed