Django return 500 error

Old question, but I hope this helps someone in the future. The accepted answer doesn’t really answer the original question…
You can do this with django rest framework easily by raising ApiException:

from rest_framework.exceptions import APIException

try:
   ...
except ...:
    raise APIException('custom exception message')

This will return a response with status 500 from your view. Pretty useful if you are calling another function from your API and you don’t want to manage return values from this function to decide if returning a response with status 500.
You can use it like this:

raise ApiException

And the default response message (at the time of writing this) will be ‘A server error occurred.’.

There’s a few predefined ApiException subclasses to raise different kinds of errors, check the file rest_framework.exceptions, if you need one that is not in there, you can extend ApiException like this:

from rest_framework.exceptions import APIException


class YourCustomApiExceptionName(APIException):
    def __init__(self, status, detail):
        self.status_code = status
        self.detail = detail

Usage:

raise YourCustomApiExceptionName(100, 'continue')

You can also define custom status and detail but wouldn’t make much sense in most cases.

from django.conf import settings
from django.urls import re_path
from django.views.static import serve

# ... the rest of your URLconf goes here ...

if settings.DEBUG:
    urlpatterns += [
        re_path(r'^media/(?P<path>.*)$', serve, {
            'document_root': settings.MEDIA_ROOT,
        }),
    ]

from django.core.exceptions import PermissionDenied

def edit(request, pk):
    if not request.user.is_staff:
        raise PermissionDenied
    # ...

Back to Top

Documentation

Built-in Views¶

Several of Django’s built-in views are documented in Writing views as well as elsewhere in the documentation.

Serving files in development¶

There may be files other than your project’s static assets that, for convenience, you’d like to have Django serve for you in local development. The serve() view can be used to serve any directory you give it. (This view is not hardened for production use and should be used only as a development aid; you should serve these files in production using a real front-end web server).

The most likely example is user-uploaded content in MEDIA_ROOT . django.contrib.staticfiles is intended for static assets and has no built-in handling for user-uploaded files, but you can have Django serve your MEDIA_ROOT by appending something like this to your URLconf:

Note, the snippet assumes your MEDIA_URL has a value of ‘media/’ . This will call the serve() view, passing in the path from the URLconf and the (required) document_root parameter.

Since it can become a bit cumbersome to define this URL pattern, Django ships with a small URL helper function static() that takes as parameters the prefix such as MEDIA_URL and a dotted path to a view, such as ‘django.views.static.serve’ . Any other function parameter will be transparently passed to the view.

Error views¶

Django comes with a few views by default for handling HTTP errors. To override these with your own custom views, see Customizing error views .

The 404 (page not found) view¶

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 “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 in the error, and exception , which is a useful representation of the exception that triggered the view (e.g. containing any message passed to a specific Http404 instance).

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.
• The 404 view is passed a RequestContext and will have access to variables supplied by your template context processors (e.g. MEDIA_URL ).
• If DEBUG is set to True (in your settings module), then your 404 view will never be used, and your URLconf will be displayed instead, with some debug information.

The 500 (server error) view¶

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 “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 with an empty Context to lessen the chance of additional errors.

If DEBUG is set to True (in your settings module), then your 500 view will never be used, and the traceback will be displayed instead, with some debug information.

The 403 (HTTP Forbidden) view¶

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 Specification). The template context contains exception , which is the string representation of the exception that triggered the view.

django.views.defaults.permission_denied is triggered by a PermissionDenied exception. To deny access in a view you can use code like this:

The 400 (bad request) view¶

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 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 views are also only used when DEBUG is False .

Источник

Exceptions

Exceptions… allow error handling to be organized cleanly in a central or high-level place within the program structure.

Exception handling in REST framework views

REST framework’s views handle various exceptions, and deal with returning appropriate error responses.

The handled exceptions are:

• Subclasses of APIException raised inside REST framework.
• Django’s Http404 exception.
• Django’s PermissionDenied exception.

In each case, REST framework will return a response with an appropriate status code and content-type. The body of the response will include any additional details regarding the nature of the error.

Most error responses will include a key detail in the body of the response.

For example, the following request:

Might receive an error response indicating that the DELETE method is not allowed on that resource:

Validation errors are handled slightly differently, and will include the field names as the keys in the response. If the validation error was not specific to a particular field then it will use the «non_field_errors» key, or whatever string value has been set for the NON_FIELD_ERRORS_KEY setting.

An example validation error might look like this:

Custom exception handling

You can implement custom exception handling by creating a handler function that converts exceptions raised in your API views into response objects. This allows you to control the style of error responses used by your API.

The function must take a pair of arguments, the first is the exception to be handled, and the second is a dictionary containing any extra context such as the view currently being handled. The exception handler function should either return a Response object, or return None if the exception cannot be handled. If the handler returns None then the exception will be re-raised and Django will return a standard HTTP 500 ‘server error’ response.

For example, you might want to ensure that all error responses include the HTTP status code in the body of the response, like so:

In order to alter the style of the response, you could write the following custom exception handler:

The context argument is not used by the default handler, but can be useful if the exception handler needs further information such as the view currently being handled, which can be accessed as context[‘view’] .

The exception handler must also be configured in your settings, using the EXCEPTION_HANDLER setting key. For example:

If not specified, the ‘EXCEPTION_HANDLER’ setting defaults to the standard exception handler provided by REST framework:

Note that the exception handler will only be called for responses generated by raised exceptions. It will not be used for any responses returned directly by the view, such as the HTTP_400_BAD_REQUEST responses that are returned by the generic views when serializer validation fails.

API Reference

APIException

Signature: APIException()

The base class for all exceptions raised inside an APIView class or @api_view .

To provide a custom exception, subclass APIException and set the .status_code , .default_detail , and default_code attributes on the class.

For example, if your API relies on a third party service that may sometimes be unreachable, you might want to implement an exception for the «503 Service Unavailable» HTTP response code. You could do this like so:

Inspecting API exceptions

There are a number of different properties available for inspecting the status of an API exception. You can use these to build custom exception handling for your project.

The available attributes and methods are:

• .detail — Return the textual description of the error.
• .get_codes() — Return the code identifier of the error.
• .get_full_details() — Return both the textual description and the code identifier.

In most cases the error detail will be a simple item:

In the case of validation errors the error detail will be either a list or dictionary of items:

ParseError

Signature: ParseError(detail=None, code=None)

Raised if the request contains malformed data when accessing request.data .

By default this exception results in a response with the HTTP status code «400 Bad Request».

AuthenticationFailed

Signature: AuthenticationFailed(detail=None, code=None)

Raised when an incoming request includes incorrect authentication.

By default this exception results in a response with the HTTP status code «401 Unauthenticated», but it may also result in a «403 Forbidden» response, depending on the authentication scheme in use. See the authentication documentation for more details.

NotAuthenticated

Signature: NotAuthenticated(detail=None, code=None)

Raised when an unauthenticated request fails the permission checks.

By default this exception results in a response with the HTTP status code «401 Unauthenticated», but it may also result in a «403 Forbidden» response, depending on the authentication scheme in use. See the authentication documentation for more details.

PermissionDenied

Signature: PermissionDenied(detail=None, code=None)

Raised when an authenticated request fails the permission checks.

By default this exception results in a response with the HTTP status code «403 Forbidden».

NotFound

Signature: NotFound(detail=None, code=None)

Raised when a resource does not exists at the given URL. This exception is equivalent to the standard Http404 Django exception.

By default this exception results in a response with the HTTP status code «404 Not Found».

MethodNotAllowed

Signature: MethodNotAllowed(method, detail=None, code=None)

Raised when an incoming request occurs that does not map to a handler method on the view.

By default this exception results in a response with the HTTP status code «405 Method Not Allowed».

NotAcceptable

Signature: NotAcceptable(detail=None, code=None)

Raised when an incoming request occurs with an Accept header that cannot be satisfied by any of the available renderers.

By default this exception results in a response with the HTTP status code «406 Not Acceptable».

Signature: UnsupportedMediaType(media_type, detail=None, code=None)

Raised if there are no parsers that can handle the content type of the request data when accessing request.data .

By default this exception results in a response with the HTTP status code «415 Unsupported Media Type».

Throttled

Signature: Throttled(wait=None, detail=None, code=None)

Raised when an incoming request fails the throttling checks.

By default this exception results in a response with the HTTP status code «429 Too Many Requests».

ValidationError

Signature: ValidationError(detail, code=None)

The ValidationError exception is slightly different from the other APIException classes:

• The detail argument is mandatory, not optional.
• The detail argument may be a list or dictionary of error details, and may also be a nested data structure. By using a dictionary, you can specify field-level errors while performing object-level validation in the validate() method of a serializer. For example. raise serializers.ValidationError(<‘name’: ‘Please enter a valid name.’>)
• By convention you should import the serializers module and use a fully qualified ValidationError style, in order to differentiate it from Django’s built-in validation error. For example. raise serializers.ValidationError(‘This field must be an integer value.’)

The ValidationError class should be used for serializer and field validation, and by validator classes. It is also raised when calling serializer.is_valid with the raise_exception keyword argument:

The generic views use the raise_exception=True flag, which means that you can override the style of validation error responses globally in your API. To do so, use a custom exception handler, as described above.

By default this exception results in a response with the HTTP status code «400 Bad Request».

Generic Error Views

Django REST Framework provides two error views suitable for providing generic JSON 500 Server Error and 400 Bad Request responses. (Django’s default error views provide HTML responses, which may not be appropriate for an API-only application.)

rest_framework.exceptions.server_error

Returns a response with status code 500 and application/json content type.

Set as handler500 :

rest_framework.exceptions.bad_request

Returns a response with status code 400 and application/json content type.

Set as handler400 :

Third party packages

The following third-party packages are also available.

DRF Standardized Errors

The drf-standardized-errors package provides an exception handler that generates the same format for all 4xx and 5xx responses. It is a drop-in replacement for the default exception handler and allows customizing the error response format without rewriting the whole exception handler. The standardized error response format is easier to document and easier to handle by API consumers.

Источник

Django — Урок 006. Кастомизация страниц ошибок 403, 404, 500

Многие ресурсы имеют оформленные страницы ошибок, если происходит сбой в обработке запроса от клиента.
Для начала на сайте была сделана кастомизация наиболее часто возникающих ошибок, другие при отладке пока не попадались, но всё впереди.

Как объявлено в заголовке статьи, кастомизированы был следующие ошибки:

1. 403 — Ошибка авторизации, доступ запрещён.
2. 404 — Страница не найдена;
3. 500 — Внутренняя ошибка сервера;

Кастомизация ошибок 404, 500

Для кастомизации ошибок 404 и 500 необходимо написать обработчики запросов, и достаточно написать их представления в виде метода.

В шаблоны добавляем свои кастомизированные html файлы, то есть:

Модуль, в котором реализованы представления для данного сайта — это home. В шаблонах этого же модуля помещены сами шаблоны кастомизированных ошибок.

В файле urls.py главного модуля сайта переопределяем обработчики по умолчанию:

В коде это выглядит так:

Опишем представления в файле views.py модуля home:

Кастомизация ошибки 403

Ошибка 403 возникает в том случае, когда не авторизованный пользователь пытается получить доступ к той части сайта, в которую доступ разрешён только авторизованным пользователям.

В Django это достигается за счёт проверки статуса пользователя и добавления на страницы защитного токена, механизм CSRF. Данная ошибка может возникнуть и в том случае, если пользователь авторизован, но совершает действия, при которых требуется проверка токена CSRF, а сам токен был потерян или не верен. Дело в том, что для корректности работы токена, необходимо добавлять в шаблоне в формах специальный тег:

В него и будет подставляться токен, но просто добавить в шаблон, его не достаточно. Прежде, чем начать рендер шаблон, необходимо добавить токен в контекст, который будет передан в шаблон. То есть,

Ну а теперь ближе к непосредственно кастомизации. Для работы csrf необходимо, чтобы в файле settings.py добавлен модуль csrf и указано представление, которое будет заниматься обработкой данной ошибки:

В шаблонах добавим error403.html, а в файле views.py пропишем обработчик представления.

Для Django рекомендую VDS-сервера хостера Timeweb .

Рекомендуем хостинг TIMEWEB

Рекомендуемые статьи по этой тематике

Источник

Whenever one tries to visit a link that doesn’t exist on a website, it gives a 404 Error, that this page is not found. Similarly, there are more error codes such as 500, 403, etc. Django has some default functions to for handle HTTP errors. Let’s explore them one-by-one.

Built-in Error Views in Django – 

404 view (page not found) – 

Normally this view is used by to render basic 404 template when requested URL is not available on the server. This situation happens by default Django raises django.views.defaults.page_not_found() view and render default404 error template. You can customize it by adding custom 404.html page inside templates folder.

500 view (server error) – 

This view is used when the server has been crashed or didn’t respond to anything. In this case Django has default function django.views.defaults.server_error() to render server error for this view. You can also customize it by adding your 500.html page inside the templates folder.

403 view (Forbidden) –

When user does not have permission to view particular page but he/she requests to view that page. In that case 403 view comes into play. It says page is forbidden and will not show page to that user. For that Django has django.views.defaults.permission_denied() function to render forbidden template. It maintains your privacy and only permitted users can access certain pages. You can also customize it by adding your 403.html page inside the templates folder.

Suppose you have an ecommerce website and you only want authenticated merchants to list products. Buyers and normal users can’t list their products. You can add this functionality in Django like this:

from django.core.exceptions import PermissionDenied

def upload(request, pk):
    if not request.user.is_merchant:
        raise PermissionDenied
 
    
    # your code here.....
        

400 view (Bad Request):

The 400 view or Bad Request view is used by Django when someone try to access confidential page of your site which may lead your site to be hacked or leak confidential data. So, you don’t want  anyone to access that page. Django has django.views.defaults.bad_request() to raise 400 view for any kind of SuspiciousOperation. This prevents your site from Bad peoples.

Customize Built-in Error Views in Django – 

Now, let’s see how to customize these error views. First of all you need to go into settings.py and set Debug=False.

DEBUG = False
ALLOWED_HOSTS =  ['localhost', '127.0.0.1']

Make folder inside the project and name it anything, here I am giving name ‘templates‘ to that folder.  Now go to settings.py and set templates directory.

TEMPLATE_DIR = os.path.join(BASE_DIR, 'templates')

Now, inside the templates directory you can create html files ‘404.html’, ‘500.html’, ‘403.html’, ‘400.html’, etc. After creating these pages show your HTML skills and customize pages by yourself. Add your app name into settings.py.

INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'jquery',
'geeks'
]

Add the handler method to urls.py

handler404 = 'myappname.views.error_404'
handler500 = 'myappname.views.error_500'
handler403 = 'myappname.views.error_403'
handler400 = 'myappname.views.error_400'

Now set logic to show these pages in views.py

from django.shortcuts import render

def error_404(request, exception):

        return render(request,'404.html')

def error_500(request,  exception):
        return render(request,'500.html', data)
        
def error_403(request, exception):

        return render(request,'403.html')

def error_400(request,  exception):
        return render(request,'400.html', data)    

Now, you are all set to run the server and see these error handling pages made by you.

To run server: python manage.py runserver

DELETE http://api.example.com/foo/bar HTTP/1.1
Accept: application/json

HTTP/1.1 405 Method Not Allowed
Content-Type: application/json
Content-Length: 42

{"detail": "Method 'DELETE' not allowed."}

HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 94

{"amount": ["A valid integer is required."], "description": ["This field may not be blank."]}

HTTP/1.1 405 Method Not Allowed
Content-Type: application/json
Content-Length: 62

{"status_code": 405, "detail": "Method 'DELETE' not allowed."}

from rest_framework.views import exception_handler

def custom_exception_handler(exc, context):
    # Call REST framework's default exception handler first,
    # to get the standard error response.
    response = exception_handler(exc, context)

    # Now add the HTTP status code to the response.
    if response is not None:
        response.data['status_code'] = response.status_code

    return response

REST_FRAMEWORK = {
    'EXCEPTION_HANDLER': 'my_project.my_app.utils.custom_exception_handler'
}

REST_FRAMEWORK = {
    'EXCEPTION_HANDLER': 'rest_framework.views.exception_handler'
}

from rest_framework.exceptions import APIException

class ServiceUnavailable(APIException):
    status_code = 503
    default_detail = 'Service temporarily unavailable, try again later.'
    default_code = 'service_unavailable'

>>> print(exc.detail)
You do not have permission to perform this action.
>>> print(exc.get_codes())
permission_denied
>>> print(exc.get_full_details())
{'message':'You do not have permission to perform this action.','code':'permission_denied'}

>>> print(exc.detail)
{"name":"This field is required.","age":"A valid integer is required."}
>>> print(exc.get_codes())
{"name":"required","age":"invalid"}
>>> print(exc.get_full_details())
{"name":{"message":"This field is required.","code":"required"},"age":{"message":"A valid integer is required.","code":"invalid"}}

serializer.is_valid(raise_exception=True)

handler500 = 'rest_framework.exceptions.server_error'

handler400 = 'rest_framework.exceptions.bad_request'

Вернуться на верх

Многие ресурсы имеют оформленные страницы ошибок, если происходит сбой в обработке запроса от клиента.

Для начала на сайте была сделана кастомизация наиболее часто возникающих ошибок, другие при отладке пока не попадались, но всё впереди.

Как объявлено в заголовке статьи, кастомизированы был следующие ошибки:

1. 403 — Ошибка авторизации, доступ запрещён.
2. 404 — Страница не найдена;
3. 500 — Внутренняя ошибка сервера;

Кастомизация ошибок 404, 500

Для кастомизации ошибок 404 и 500 необходимо написать обработчики запросов, и достаточно написать их представления в виде метода.

В шаблоны добавляем свои кастомизированные html файлы, то есть:

• error404.html
• error500.html

Модуль, в котором реализованы представления для данного сайта — это

home.

В шаблонах этого же модуля помещены сами шаблоны кастомизированных ошибок.

В файле

urls.py

главного модуля сайта переопределяем обработчики по умолчанию:

• handler404
• handler500

В коде это выглядит так:

from home.views import e_handler404, e_handler500

handler404 = e_handler404
handler500 = e_handler500


  Опишем представления в файле

  

   views.py

  

  модуля

  

   home:

  
from django.shortcuts import render_to_response
from django.template import RequestContext


def e_handler404(request):
    context = RequestContext(request)
    response = render_to_response('error404.html', context)
    response.status_code = 404
    return response


def e_handler500(request):
    context = RequestContext(request)
    response = render_to_response('error500.html', context)
    response.status_code = 500
    return response


  Кастомизация ошибки 403

 

  Ошибка 403 возникает в том случае, когда не авторизованный пользователь пытается получить доступ к той части сайта, в которую доступ разрешён только авторизованным пользователям.
 

  В Django это достигается за счёт проверки статуса пользователя и добавления на страницы защитного токена, механизм

  

   CSRF.

  

  Данная ошибка может возникнуть и в том случае, если пользователь авторизован, но совершает действия, при которых требуется проверка токена CSRF, а сам токен был потерян или не верен. Дело в том, что для корректности работы токена, необходимо добавлять в шаблоне в формах специальный тег:
 
{% csrf_token %}


  В него и будет подставляться токен, но просто добавить в шаблон, его не достаточно. Прежде, чем начать рендер шаблон, необходимо добавить токен в контекст, который будет передан в шаблон. То есть,
 
from django.template.context_processors import csrf
from django.shortcuts import render_to_response


def any_request(request):
    context = {}
    context.update(csrf(request))

    ...
    return render_to_response('any_request.html', context=context)


  Ну а теперь ближе к непосредственно кастомизации. Для работы csrf необходимо, чтобы в файле

  

   settings.py

  

  добавлен модуль csrf и указано представление, которое будет заниматься обработкой данной ошибки:
 
MIDDLEWARE = [
    ...
    'django.middleware.csrf.CsrfViewMiddleware',
    ...
]

CSRF_FAILURE_VIEW = 'home.views.csrf_failure'


  В шаблонах добавим

  

   error403.html,

  

  а в файле

  

   views.py

  

  пропишем обработчик представления.
 
def csrf_failure(request, reason=""):
    context = RequestContext(request)
    response = render_to_response('error403.html', context)
    response.status_code = 403
    return response


  Для

  

   Django

  

  рекомендую
   VDS-сервера хостера Timeweb
  .
 

In this tutorial, we’ll learn how to create Django custom 404 and 505 Error pages.

1. Django Project structure

├── core
│   ├── admin.py
│   ├── apps.py
│   ├── forms.py
│   ├── __init__.py
│   ├── migrations
│   ├── models.py
│   ├── __pycache__
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── db.sqlite3
├── manage.py
├── media
├── pypro
│   ├── __init__.py
│   ├── __pycache__
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── static
└── TEMPLATES

2. Views.py

In our views project, we need to add these two functions.

def handler404(request, exception):
    return render(request, 'err/404.html', status=404)

def handler500(request):
    return render(request, 'err/500.html', status=500)

handler404 function: return 404 not found page.

handler500 function: return 500 Internal Server Error page.

3. urls.py

In our base project URLs, we need to import & defined our page function.

#pypro/urls.py

from core import views

handler404 = views.handler404
handler500 = views.handler500

4. settings.py

In our settings.py, we must set debug = False.

#pypro/settings.py

DEBUG = False

5. Create custom 500 & 404 page Template

Now, we’ll create the template for our page, so in the TEMPLATES folder, we need to create an err folder, and inside of this folder, we’ll create 404.html & 500.html.

404.html

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
   

    <title>404 HTML Template by Colorlib</title>

    <!-- Google font -->
    <link href="https://fonts.googleapis.com/css?family=Fredoka+One" rel="stylesheet">
    <link href="https://fonts.googleapis.com/css?family=Raleway:400,700" rel="stylesheet">

    <!-- Custom stlylesheet -->
    <style type="text/css">
        
        * {
  -webkit-box-sizing: border-box;
          box-sizing: border-box;
}

body {
  padding: 0;
  margin: 0;
}

#notfound {
  position: relative;
  height: 100vh;
}

#notfound .notfound {
  position: absolute;
  left: 50%;
  top: 50%;
  -webkit-transform: translate(-50%, -50%);
      -ms-transform: translate(-50%, -50%);
          transform: translate(-50%, -50%);
}

.notfound {
  max-width: 710px;
  width: 100%;
  text-align: center;
  padding: 0px 15px;
  line-height: 1.4;
}

.notfound .notfound-404 {
  height: 200px;
  line-height: 200px;
}

.notfound .notfound-404 h1 {
  font-family: 'Fredoka One', cursive;
  font-size: 168px;
  margin: 0px;
  color: #1e50dc;
  text-transform: uppercase;
}

.notfound h2 {
  font-family: 'Raleway', sans-serif;
  font-size: 22px;
  font-weight: 400;
  text-transform: uppercase;
  color: #222;
  margin: 0;
}

.notfound-search {
  position: relative;
  padding-right: 123px;
  max-width: 420px;
  width: 100%;
  margin: 30px auto 22px;
}

.notfound-search input {
  font-family: 'Raleway', sans-serif;
  width: 100%;
  height: 40px;
  padding: 3px 15px;
  color: #222;
  font-size: 18px;
  background: #f8fafb;
  border: 1px solid rgba(34, 34, 34, 0.2);
  border-radius: 3px;
}

.notfound-search button {
  font-family: 'Raleway', sans-serif;
  position: absolute;
  right: 0px;
  top: 0px;
  width: 120px;
  height: 40px;
  text-align: center;
  border: none;
  background: #1e50dc;
  cursor: pointer;
  padding: 0;
  color: #fff;
  font-weight: 700;
  font-size: 18px;
  border-radius: 3px;
}

.notfound a {
  font-family: 'Raleway', sans-serif;
  display: inline-block;
  font-weight: 700;
  border-radius: 15px;
  text-decoration: none;
  color: #39b1cb;
}

.notfound a>.arrow {
  position: relative;
  top: -2px;
  border: solid #39b1cb;
  border-width: 0 3px 3px 0;
  display: inline-block;
  padding: 3px;
  -webkit-transform: rotate(135deg);
      -ms-transform: rotate(135deg);
          transform: rotate(135deg);
}

@media only screen and (max-width: 767px) {
  .notfound .notfound-404 {
    height: 122px;
    line-height: 122px;
  }
  .notfound .notfound-404 h1 {
    font-size: 122px;
  }
}


    </style>

    <!-- HTML5 shim and Respond.js for IE8 support of HTML5 elements and media queries -->
    <!-- WARNING: Respond.js doesn't work if you view the page via file:// -->
    <!--[if lt IE 9]>
          <script src="https://oss.maxcdn.com/html5shiv/3.7.3/html5shiv.min.js"></script>
          <script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
        <![endif]-->

</head>

<body>

    <div id="notfound">
        <div class="notfound">
            <div class="notfound-404">
                <h1>404</h1>
            </div>
            <h2>Oops, The Page you are looking for can't be found!</h2>
            
            <a href="/"><span class="arrow"></span>Return To Homepage</a>
        </div>
    </div>

</body><!-- This templates was made by Colorlib (https://colorlib.com) -->

</html>

500.html

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
   

    <title>404 HTML Template by Colorlib</title>

    <!-- Google font -->
    <link href="https://fonts.googleapis.com/css?family=Fredoka+One" rel="stylesheet">
    <link href="https://fonts.googleapis.com/css?family=Raleway:400,700" rel="stylesheet">

    <!-- Custom stlylesheet -->
    <style type="text/css">
        
        * {
  -webkit-box-sizing: border-box;
          box-sizing: border-box;
}

body {
  padding: 0;
  margin: 0;
}

#notfound {
  position: relative;
  height: 100vh;
}

#notfound .notfound {
  position: absolute;
  left: 50%;
  top: 50%;
  -webkit-transform: translate(-50%, -50%);
      -ms-transform: translate(-50%, -50%);
          transform: translate(-50%, -50%);
}

.notfound {
  max-width: 710px;
  width: 100%;
  text-align: center;
  padding: 0px 15px;
  line-height: 1.4;
}

.notfound .notfound-404 {
  height: 200px;
  line-height: 200px;
}

.notfound .notfound-404 h1 {
  font-family: 'Fredoka One', cursive;
  font-size: 168px;
  margin: 0px;
  color: #1e50dc;
  text-transform: uppercase;
}

.notfound h2 {
  font-family: 'Raleway', sans-serif;
  font-size: 22px;
  font-weight: 400;
  text-transform: uppercase;
  color: #222;
  margin: 0;
}

.notfound-search {
  position: relative;
  padding-right: 123px;
  max-width: 420px;
  width: 100%;
  margin: 30px auto 22px;
}

.notfound-search input {
  font-family: 'Raleway', sans-serif;
  width: 100%;
  height: 40px;
  padding: 3px 15px;
  color: #222;
  font-size: 18px;
  background: #f8fafb;
  border: 1px solid rgba(34, 34, 34, 0.2);
  border-radius: 3px;
}

.notfound-search button {
  font-family: 'Raleway', sans-serif;
  position: absolute;
  right: 0px;
  top: 0px;
  width: 120px;
  height: 40px;
  text-align: center;
  border: none;
  background: #1e50dc;
  cursor: pointer;
  padding: 0;
  color: #fff;
  font-weight: 700;
  font-size: 18px;
  border-radius: 3px;
}

.notfound a {
  font-family: 'Raleway', sans-serif;
  display: inline-block;
  font-weight: 700;
  border-radius: 15px;
  text-decoration: none;
  color: #39b1cb;
}

.notfound a>.arrow {
  position: relative;
  top: -2px;
  border: solid #39b1cb;
  border-width: 0 3px 3px 0;
  display: inline-block;
  padding: 3px;
  -webkit-transform: rotate(135deg);
      -ms-transform: rotate(135deg);
          transform: rotate(135deg);
}

@media only screen and (max-width: 767px) {
  .notfound .notfound-404 {
    height: 122px;
    line-height: 122px;
  }
  .notfound .notfound-404 h1 {
    font-size: 122px;
  }
}


    </style>

    <!-- HTML5 shim and Respond.js for IE8 support of HTML5 elements and media queries -->
    <!-- WARNING: Respond.js doesn't work if you view the page via file:// -->
    <!--[if lt IE 9]>
          <script src="https://oss.maxcdn.com/html5shiv/3.7.3/html5shiv.min.js"></script>
          <script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
        <![endif]-->

</head>

<body>

    <div id="notfound">
        <div class="notfound">
            <div class="notfound-404">
                <h1>404</h1>
            </div>
            <h2>Oops, The Page you are looking for can't be found!</h2>
            
            <a href="/"><span class="arrow"></span>Return To Homepage</a>
        </div>
    </div>

</body><!-- This templates was made by Colorlib (https://colorlib.com) -->

</html>

Done!

Now, it’s time to test our 404 & 500 error pages.

6. Result

before:

after: