Урок 2 кастомные страницы ошибок тестирование страницы 404

10 июля, 2015 12:54 пп
1 573 views
| Комментариев нет

Centos, Cloud Server, VPS

Apache – самый популярный в мире веб-сервер; многофункциональный и гибкий, он постоянно развивается и поддерживается командой высококвалифицированных специалистов.

При проектировании веб-страниц часто возникает необходимость настроить каждую страницу индивидуально. Это касается и страниц ошибок, которые появляются, если запрашиваемый контент по какой-либо причине недоступен. В этом руководстве показано, как настроить Apache для отображения пользовательских страниц ошибок в системе CentOS 7.

Требования

Для выполнения данного руководства нужна уётная запись пользователя с привилегиями sudo. Чтобы настроить такого пользователя, обратитесь к этому руководству. Кроме того, нужно предварительно установить Apache; подробные инструкции по установке веб-сервера можно получить здесь.

Создание пользовательской страницы ошибок

Для начала создайте пользовательские страницы ошибок.

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

Страницы ошибок будут находиться в каталоге /var/www/html – стандартном каталоге document root веб-сервера Apache. Для примера создайте страницу ошибки 404 (по имени custom_404.html) и общую страницу для ошибок 500 (назовите её custom_50x.html).

echo "<h1 style='color:red'>Error 404: Not found :-(</h1>" | sudo tee /var/www/html/custom_404.html
echo "<p>I have no idea where that file is, sorry.  Are you sure you typed in the correct URL?</p>" | sudo tee -a /var/www/html/custom_404.html
echo "<h1>Oops! Something went wrong...</h1>" | sudo tee /var/www/html/custom_50x.html
echo "<p>We seem to be having some technical difficulties. Hang tight.</p>" | sudo tee -a /var/www/html/custom_50x.html

Итак, теперь на сервере есть две страницы ошибок.

Настройка Apache для отображения пользовательских страниц ошибок

Теперь нужно настроить Apache для поддержки только что созданных страниц в случае возникновения соответствующей ошибки. Создайте новый конфигурационный файл в каталоге /etc/httpd/conf.d, который хранит настройки для Apache. Назовите файл custom_errors.conf:

sudo nano /etc/httpd/conf.d/custom_errors.conf

Направьте Apache на соответствующие страницы ошибок.

Для того чтобы связать каждый тип ошибки со специальной страницей ошибок, используйте директиву ErrorDocument. В целом, нужно просто указать код состояния HTTP для каждой страницы, и тогда страница появится на экране в случае возникновения указанной ошибки.

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

/etc/httpd/conf.d/custom_errors.conf
ErrorDocument 404 /custom_404.html
ErrorDocument 500 /custom_50x.html
ErrorDocument 502 /custom_50x.html
ErrorDocument 503 /custom_50x.html
ErrorDocument 504 /custom_50x.html

Этих настроек достаточно, чтобы обслуживать пользовательские страницы ошибок.

Однако рекомендуется добавить ещё один блок конфигураций, чтобы клиенты не могли запрашивать страницы ошибок напрямую. Это предотвратит путаницу (например, запрошенная напрямую страница ошибки будет сообщать пользователю об ошибке, даже если код состояния – 200 (Success)).

Чтобы настроить такое поведение веб-сервера, нужно добавить блок Files для каждой пользовательской страницы ошибок. Также нужно проверить, установлена ли переменная окружения REDIRECT_STATUS; она должна быть установлена только если директива ErrorDocument обрабатывает запрос. Если переменная окружения пуста, сервер будет обслуживать страницу 404:

/etc/httpd/conf.d/custom_errors.conf
ErrorDocument 404 /custom_404.html
ErrorDocument 500 /custom_50x.html
ErrorDocument 502 /custom_50x.html
ErrorDocument 503 /custom_50x.html
ErrorDocument 504 /custom_50x.html
<Files "custom_404.html">
<If "-z %{ENV:REDIRECT_STATUS}">
RedirectMatch 404 ^/custom_404.html$
</If>
</Files>
<Files "custom_50x.html">
<If "-z %{ENV:REDIRECT_STATUS}">
RedirectMatch 404 ^/custom_50x.html$
</If>
</Files>

Когда страницы ошибок запрашиваются клиентами, возникает ошибка 404, потому что переменная среды не установлена.

Тестирование страницы ошибок 500

Проверить работу страницы ошибок 404 очень просто: нужно запросить любой несуществующий контент. Чтобы протестировать страниц ошибок 500, нужно создать фиктивный ProxyPass.

Добавьте директиву ProxyPass в конец конфигурационного файла. Отправьте запросы для /proxytest на порт 9000 на локальной машине (на этом порте не запущено ни одного сервиса):

/etc/httpd/conf.d/custom_errors.conf
ErrorDocument 404 /custom_404.html
ErrorDocument 500 /custom_50x.html
ErrorDocument 502 /custom_50x.html
ErrorDocument 503 /custom_50x.html
ErrorDocument 504 /custom_50x.html
<Files "custom_404.html">
<If "-z %{ENV:REDIRECT_STATUS}">
RedirectMatch 404 ^/custom_404.html$
</If>
</Files>
<Files "custom_50x.html">
<If "-z %{ENV:REDIRECT_STATUS}">
RedirectMatch 404 ^/custom_50x.html$
</If>
</Files>
ProxyPass /proxytest "http://localhost:9000"

Сохраните и закройте файл.

Тестирование страниц ошибок

Проверьте конфигурационный файл на наличие ошибок:

sudo apachectl configtest

Если команда обнаружила любые ошибки, исправьте их. После этого перезапустите Apache:

sudo systemctl restart httpd

Откройте домен или IP-адрес сервера и запросите несуществующий контент, чтобы проверить работу страницы 404:

http://server_domain_or_IP/thiswillerror

На экране должна появиться страница 404:

Error 404: Not found :-(
I have no idea where that file is, sorry.  Are you sure you typed in the correct URL?

Откройте фиктивный proxypass, чтобы проверить работу страницы 500 (на экране должен появиться код состояния 503 service unavailable):

http://server_domain_or_IP/proxytest

Если всё настроено верно, на экране появится:

Oops! Something went wrong...
We seem to be having some technical difficulties. Hang tight.

После тестирования удалите фиктивную директиву из конфигураций Apache.

Заключение

Итак, теперь на сайте есть уникальные страницы ошибок. Пользовательские страницы ошибок – это отличный способ помочь посетителям понять, в чём дело, предоставить им всю необходимую информацию об ошибке и полезные ссылки (не забудьте убедиться, что ссылки работают даже в случае возникновения ошибок).

Tags: Apache, CentOS 7

Яндекс.Практикум

курс Python-разработчик

студент Leonid Slavutin

Проект sprint_6. Подписки на авторов.


Шаблоны и структура проекта заданы.

Задачи проекта:

  • В проект добавлены кастомные страницы ошибок:

    404 page_not_found

    500 server_error

    403 permission_denied_view

    Написан тест, проверяющий, что страница 404 отдает кастомный шаблон.

  • С помощью sorl-thumbnail выведены иллюстрации к постам.

    Написаны тесты, которые проверяют работу с изображениями.

  • Создана система комментариев

  • Добавлены:

    Кеширование главной страницы

    Тестирование кэша

  • Добавлена система подписки на авторов.


Разворачивание проекта:

Клонировать репозиторий и перейти в его папку в командной строке:

git clone https://github.com/coherentus/hw05_final
cd hw05_final

Cоздать и активировать виртуальное окружение:

Для *nix-систем и MacOS:

Для windows-систем:

source venv/Scripts/activate

Установить зависимости из файла requirements.txt:

python3 -m pip install --upgrade pip
pip install -r requirements.txt

Выполнить миграции:

cd yatube
python3 manage.py migrate

Запустить проект:

python3 manage.py runserver

Создать суперпользователя Django:

python3 manage.py createsuperuser

Сам проект и админ-панель по адресам:

http://127.0.0.1:8000

http://127.0.0.1:8000/admin

Режим отладки проекта

Сейчас ваш проект работает в режиме отладки: при установке проекта в конфиге был автоматически выставлен флаг DEBUG=True. В этом режиме при ошибках выводится страница с технической информацией и подробным разбором строк, в которых что-то пошло не так.

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

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

Страницы ошибок

Чтобы отключить режим отладки (его ещё называют «режим разработки» или «режим разработчика»), в settings.py нужно установить значение DEBUG=False. После этого страницы с ошибками вы увидите в совершенно ином виде.

В Django есть предустановленные страницы ошибок (например, для ошибки 404 — «страница не найдена» или для 403 — «запрос отклонён»); однако выглядят эти страницы так, будто разработчику сайта не было до них дела. Нельзя оставлять их в таком виде: пользователи будут неприятно изумлены.

Создадим собственные страницы ошибок; они относятся ко всему проекту, поэтому будет логично описать их view-функции и шаблоны в приложении core.

Ошибка 404: страница не найдена

Подготовим view-функцию для страницы 404:

# core/views.py
from django.shortcuts import render

def page_not_found(request, exception):
    # Переменная exception содержит отладочную информацию; 
    # выводить её в шаблон пользовательской страницы 404 мы не станем
    return render(request, 'core/404.html', {'path': request.path}, status=404)
 

Шаблон этой страницы будет таким:

# templates/core/404.html
{% extends "base.html" %}
{% block title %}Custom 404{% endblock %}
{% block content %}
  <h1>Custom 404</h1>
  <p>Страницы с адресом {{ path }} не существует</p>
  <a href="{% url 'home:index' %}"> Идите на главную</a>
{% endblock %} 

Django распознаёт ошибки и вызывает для их обработки заготовленные view-функции. Имена этих функций хранятся в специальных переменных — хендлерах (англ. handlers). Адрес view-функции с ошибкой 404 хранится в переменной handler404 (по умолчанию это view-функция django.views.defaults.page_not_found).

Хендлер можно переопределить: передать в него имя собственной view-функции. Для этого достаточно добавить в головной url-файл проекта такую строчку:

# urls.py

handler404 = 'core.views.page_not_found'
 

В результате при ошибке 404 отработает view-функция page_not_found() и отобразится кастомная страница ошибки. А уж настроить эту страницу — дело фронтендера.

Разумеется, дизайн может быть каким угодно.

Обработка прочих ошибок выполняется точно так же. В Django заготовлены переменные handler400handler403 и несколько других, в документации есть их перечень.

403: ошибка проверки CSRF, запрос отклонён

Ошибка 403 в Django появится в том случае, если при отправке формы не был отправлен csrf-токен. Страница этой ошибки кастомизируется немного иначе: view-функция и шаблон готовятся, как и для других страниц, но переопределяется не хандлер, а константа CSRF_FAILURE_VIEW в settings.py.

View-функция:

# core/views.py
from django.shortcuts import render

def csrf_failure(request, reason=''):
    return render(request, 'core/403csrf.html')
 

Шаблон:

# templates/core/403csrf.html
{% extends "base.html" %}
{% block content %}
  <h1>Custom CSRF check error. 403</h1>
{% endblock %} 

Имя view-функции, обрабатывающей ошибку 403, указывается в settings.py, в константе CSRF_FAILURE_VIEW:

PYTHON# settings.py

CSRF_FAILURE_VIEW = 'core.views.csrf_failure'
 

Включение и отключение режима отладки

При разработке реальных проектов вы будете публиковать их на сервере, при этом нужно будет отключать режим отладки. Для этого в файле settings.py нужно установить значение ключа DEBUG=False.

После отключения режима разработки у вас перестанет показываться статика. Это нормально: в «боевом режиме» Django ожидает, что статику будет раздавать специально настроенный сервер.

После отключения режима разработки может возникнуть и другая проблема: при обращении к страницам сайта может вернуться ошибка 400: Bad Request. Эта ошибка может возникнуть как на локальном компьютере, так и на удалённом сервере.

Причина — в settings.py в списке ALLOWED_HOSTS не указан адрес вашего сервера.

Проверьте этот список, в нём должны быть указаны адреса, на которых может быть размещён проект:

DEBUG = False

ALLOWED_HOSTS = [
    'localhost',
    '127.0.0.1',
    '[::1]',
    'testserver',
] 

После проверки работы шаблонов не забудьте вернуть сайт в режим разработки:

DEBUG = True 

В зависимости от задач можно по-разному переопределить в Django стандартное поведение на реакцию ошибок, таких как 403, 404, 500 и стандартные шаблоны вывода ошибок. В официальной документации (на рус. яз. — http://djbook.ru/rel1.8/topics/http/views.html) хорошо это описывается, но тем не менее есть некоторые нюансы, о которых я хочу рассказать и показать в примерах.

В большинстве случаев можно оставить стандартное поведение Django, т. е. стандартные views (из django.views.defaults), обрабатывающие ошибки и переопределить только шаблоны.

Допустим, у нас есть шаблон ошибки 404:

# 404.html
{% extends "base.html" %}

{% block subtitle %}Страница не найдена{% endblock %}
{% block meta %}<meta name="robots" content="noindex, nofollow">{% endblock %}

{% block content %}
    <h2>Запрашиваемая страница не найдена</h2>
    <p>Возможно, неправильно указан путь в адресной строке или страница была удалена.</p>
    <p>Возврат на <a href="/">главную страницу</a></p>
{% endblock %}

А ниже описаны разные способы переопределения.

Добавление своего шаблона в templates

Самый простой способ переопределения — это добавить этот шаблон в «my_project / templates». Именно здесь django будет искать шаблон 404.html и при наличии отрендерит.

Добавление своего шаблона в другую папку

Не всегда удобно держать шаблоны ошибок в «my_project / templates» вместе с какими-то другими шаблонами и хочется их вынести в отдельную папку. Я, к примеру, использую следующую структуру папки templates в корне проекта (жирным выделены папки):

  • admin — содержит переопределяемые админские шаблонов
  • cms — содержит переопределяемые шаблоны Django CMS
  • errs — содержит шаблоны ошибок
    • 403.html
    • 404.html
    • 500.html
  • vers — содержит проверочные файлы для поисковых систем
  • base.html
  • one_col.html
  • two_col.html
  • main.html

Как видите, вынос шаблонов ошибок в отдельную папку — хорошая идея отделить их от шаблонов страниц (one_col.html, two_col.html, main.html). Чтобы указать django, где искать шаблоны по новому пути, нужно использовать метод curry, например:

# urls.py
from django.views.defaults import server_error, page_not_found, permission_denied

handler403 = curry(permission_denied, template_name='errs/403.html')
handler404 = curry(page_not_found, template_name='errs/404.html')
handler500 = curry(server_error, template_name='errs/500.html')

Замечание: в Django>=1.9 нужно добавить ещё один аргумент exception для handler403 и handler404:

handler403 = curry(permission_denied, exception=Exception('Permission Denied'), template_name='errs/403.html')
handler404 = curry(page_not_found, exception=Exception('Page not Found'), template_name='errs/404.html')

Тестирование своих шаблонов ошибок

Чтобы протестировать шаблоны ошибок, достаточно добавить соответствующие urls в urls.py, например так:

if settings.DEBUG:
    urlpatterns = [
        url(r'^media/(?P<path>.*)$', serve, {'document_root': settings.MEDIA_ROOT, 'show_indexes': True}),
        url(r'', include('django.contrib.staticfiles.urls')),

        # --- error pages ---
        url(r'^403$', handler403),
        url(r'^404$', handler404),
        url(r'^500$', handler500),
    ] + urlpatterns

Теперь можно переходить по адресу http://localhost:8000/404 и видеть свой кастомный шаблон ошибки. На боевом сайте нам тестовые урлы ошибок не нужны, поэтому мы добавили их в условие if settings.DEBUG:.

Создание своего представления для обработки ошибки

Если хочется изменить стандартное поведение обработки ошибок, то нужно писать своё представление. Например:

# urls.py
handler403 = 'my_app.views.show_403'
handler404 = 'my_app.views.show_404'

# my_app/views.py
# Обработка ошибки 403
from django.core.exceptions import PermissionDenied
def show_403(request):
    # какие-либо действия
    raise PermissionDenied

# Обработка ошибки 404
from django.http.response import Http404
def show_404(request):
    # какие-либо действия
    raise Http404

Можно усложнить пример с обработкой ошибки 404. Например, мы хотим отдавать разные шаблоны 404 в зависимости от того, с чего начинается отсутствующий url:

# Обработка ошибки 404
from django.http.response import Http404
def 404(request):
    if request.path.startswith('/project/'):
        return render(request, 'project_not_found.html')  # выдаст страницу, что проекта нет и, к примеру, покажет другие проекты
    if request.path.startswith('/shop/'):
        return render(request, 'product_not_found.html')  # выдаст страницу, что товара нет и, к примеру, покажет другие товары

    raise Http404  # в остальных случаях показать стандартное исключение, которое отрендерит наш шаблон 404.html

Некоторые тонкости

Проверка отдачи шаблона 404

Для проверки отдачи шаблона 404 используйте при значении переменной DEBUG=False в settings.py, иначе вам будет показан трейсбек Django.

Внимание! Если DEBUG=False, то вы должны добавить в ALLOWED_HOSTSsettings.py) допустимые доменные имена, иначе Django будет выдавать ошибку “Bad Request (400)”. На локальной машине добавляется ‘localhost’ (или 127.0.0.1).

# settings.py
ALLOWED_HOSTS = ['localhost', ]

Обратите внимание, что при DEBUG=False статические файлы не будут показываться. Для показа статических файлов нужно собрать статику и запустить сервер с опцией --insecure:

python manage.py collectstatic
python manage.py runserver --insecure

Создание своего представления для обработки 500 ошибки

При использовании стандартного представления обработки 500 ошибки в соответствующий шаблон не передаётся контекст. Сделано так для того, чтобы уменьшить количество возможных других ошибок. Поэтому шаблон должен быть простой подобный этому:

<!DOCTYPE html>
<html>
<head>
    <title>Ошибка на стороне сервера</title>
    <meta name="robots" content="noindex, nofollow">
</head>
<body>
    <p>Извините, но что-то случилось с сайтом.</p>
    <p>В техническую поддержку уже отправлено уведомление.</p>
</body>
</html>

Если будете делать своё представление для 500 ошибки, то следуйте правилам django — не передавайте RequestContext при рендеринге шаблона. Посмотрите как происходит обработка в стандартном представлении django.views.defaults.server_error.

Отображение ошибок без рендеринга шаблонов

from django.http import HttpResponseNotFound 

def test_view_1(request, param):  
  if not param:  # какое-то условие
    return HttpResponseNotFound('<p>Страница не найдена</p>')  

  return render_to_response('test_view_1.html')  


from django.http.response import HttpResponseForbidden
def test_view_2(request, param):
    if not param:
        return HttpResponseForbidden('Доступ запрещён')

    return render_to_response('test_view_2.html')

Надеюсь, статья помогла ответить на возникающие вопросы об обработке ошибок в Django.

Оцените статью

3.9 из 5 (всего 7 оценок)

После нажатия кнопки «Отправить» ваше сообщение будет доставлено мне на почту.

Артём Мальцев

Веб-разработчик, владеющий знаниями языка программирования Python, фреймворка Django, системы управления содержимым сайта Django CMS, платформы для создания интернет-магазина Django Shop и многих различных приложений, использующих эти технологии.

Права на использование материала, расположенного на этой странице https://vivazzi.pro/ru/it/django-custom-templates-for-errors/:

Разрешается копировать материал с указанием её автора и ссылки на оригинал без использования параметра rel="nofollow" в теге <a>. Использование:

Автор статьи: Артём Мальцев
Ссылка на статью: <a href="https://vivazzi.pro/ru/it/django-custom-templates-for-errors/">https://vivazzi.pro/ru/it/django-custom-templates-for-errors/</a>

Больше: Правила использования сайта

Представляю вашему вниманию книгу, написанную моим близким другом Максимом Макуриным: Секреты эффективного управления ассортиментом.

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

Узнайте, как настроить кастомные 404 и 500 страницы на вашем сайте для улучшения пользовательского опыта и профессионализма!

Кастомные 404 и 500 страницы являются важными элементами любого сайта, так как они помогают пользователю понять, что что-то пошло не так, и предлагают дальнейшие действия для решения проблемы. В этой статье мы рассмотрим, как настроить кастомные 404 и 500 страницы на сайте.

Что такое 404 и 500 ошибки

404 ошибка отображается, когда пользователь пытается получить доступ к несуществующей странице на вашем сайте, а 500 ошибка возникает, когда сервер сталкивается с внутренней проблемой и не может обработать запрос пользователя. Создание кастомных страниц для этих ошибок позволяет вам предоставить более дружественную и полезную информацию для пользователей.

Настройка кастомной 404 страницы

Для настройки кастомной 404 страницы выполните следующие шаги:

  1. Создайте новый HTML-файл с именем 404.html.
  2. Добавьте в этот файл HTML-содержимое, которое вы хотите отображать на кастомной странице 404.
  3. Загрузите файл 404.html на ваш сервер в корневую директорию сайта.

Теперь, когда пользователи попадут на несуществующую страницу, они увидят вашу кастомную 404 страницу.

😉 Пример содержимого файла 404.html:

<!DOCTYPE html>
<html>
<head>
  <title>404 - Страница не найдена</title>
</head>
<body>
  <h1>Ошибка 404</h1>
  <p>К сожалению, запрашиваемая вами страница не найдена. Возможно, она была удалена или перемещена.</p>
  <a href="/">Вернуться на главную страницу</a>
</body>
</html>

Настройка кастомной 500 страницы

Настройка кастомной 500 страницы аналогична настройке 404 страницы:

  1. Создайте новый HTML-файл с именем 500.html.
  2. Добавьте в этот файл HTML-содержимое, которое вы хотите отображать на кастомной странице 500.
  3. Загрузите файл 500.html на ваш сервер в корневую директорию сайта.

Теперь, когда сервер столкнется с внутренней ошибкой, пользователи увидят вашу кастомную 500 страницу.

😉 Пример содержимого файла 500.html:

<!DOCTYPE html>
<html>
<head>
  <title>500 - Внутренняя ошибка сервера</title>
</head>
<body>
  <h1>Ошибка 500</h1>
  <p>Извините, на сервере произошла внутренняя ошибка. Мы работаем над ее устранением.</p>
  <a href="/">Вернуться на главную страницу</a>
</body>
</html>

Веб-разработчик: новая работа через 9 месяцев

Получится, даже если у вас нет опыта в IT

Узнать больше

Теперь вы знаете, как настроить кастомные 404 и 500 страницы на вашем сайте. Это поможет улучшить пользовательский опыт и сделать ваш сайт более профессиональным. Удачи в веб-разработке!

Я пытаюсь автоматизировать тестирование 404 страниц с помощью платформы тестирования Django 1.4.

если я распечатаю 127.0.0.1:8000/something/really/weird/ в адресной строке браузера с запущенным сервером разработки я вижу страницу 404 с правильным статусом «404 не найден» (как показывает firebug).

но если я пытаюсь использовать этот код для проверки:

from django.test import TestCase
class Sample404TestCase(TestCase):
    def test_wrong_uri_returns_404(self):
        response = self.client.get('something/really/weird/')
        self.assertEqual(response.status_code, 404)

тест терпит неудачу с этим выходом:

$./manage.py test main
Creating test database for alias 'default'...
.F
======================================================================
FAIL: test_wrong_uri_returns_404 (main.tests.Sample404TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".../main/tests.py", line 12, in test_wrong_uri_returns_404
    self.assertEqual(response.status_code, 404)
*AssertionError: 200 != 404*

----------------------------------------------------------------------
Ran 2 tests in 0.031s

FAILED (failures=1)
Destroying test database for alias 'default'...

Я серьезно удивлен, получив 200 код здесь. Кто-нибудь знает, почему на земле это происходит?

обновление:

здесь лежит urls.py:http://pastebin.com/DikAVa8T
и фактический неудачный тест:

def test_wrong_uri_returns_404(self):
    response = self.client.get('/something/really/weird/')
    self.assertEqual(response.status_code, 404)

все происходит в проекте https://github.com/gbezyuk/django-app-skeleton

2 ответов


проблема в том, что ваш класс ViewFor404 возвращает код состояния 200. Посмотрите на определение TemplateView Джанго:

class TemplateView(TemplateResponseMixin, View):
    """
    A view that renders a template.
    """
    def get_context_data(self, **kwargs):
        return {
            'params': kwargs
        }

    def get(self, request, *args, **kwargs):
        context = self.get_context_data(**kwargs)
        return self.render_to_response(context)

Так что все ваши класса является render_to_response, который генерирует ‘200’ ответ.

Если вам нужно переопределить обработчик 404, вы должны сделать что-то вроде этого в представлении:

return HttpResponseNotFound('<h1>Page not found</h1>')

(Я не знаю эквивалента в представлениях на основе классов)

или еще лучше, вы можете избежать настройки посмотреть? К настроить отображение 404, вы можете просто создать 404.html-шаблон (в шаблонах/ каталоге вашего сайта), и он будет подхвачен средством просмотра ошибок Django.


попробовать

response = self.client.get('/something/really/weird/') # note the '/' before something

127.0.0.1:8000/something/really/weird/ is /something/really/weird/ в пути относительно корня,не

  • something/really/weird
  • something/really/weird/
  • /something/really/weird

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

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

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

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

  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

.

10 июля, 2015 12:54 пп
1 586 views
| Комментариев нет

Centos, Cloud Server, VPS

Apache – самый популярный в мире веб-сервер; многофункциональный и гибкий, он постоянно развивается и поддерживается командой высококвалифицированных специалистов.

При проектировании веб-страниц часто возникает необходимость настроить каждую страницу индивидуально. Это касается и страниц ошибок, которые появляются, если запрашиваемый контент по какой-либо причине недоступен. В этом руководстве показано, как настроить Apache для отображения пользовательских страниц ошибок в системе CentOS 7.

Требования

Для выполнения данного руководства нужна уётная запись пользователя с привилегиями sudo. Чтобы настроить такого пользователя, обратитесь к этому руководству. Кроме того, нужно предварительно установить Apache; подробные инструкции по установке веб-сервера можно получить здесь.

Создание пользовательской страницы ошибок

Для начала создайте пользовательские страницы ошибок.

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

Страницы ошибок будут находиться в каталоге /var/www/html – стандартном каталоге document root веб-сервера Apache. Для примера создайте страницу ошибки 404 (по имени custom_404.html) и общую страницу для ошибок 500 (назовите её custom_50x.html).

echo "<h1 style='color:red'>Error 404: Not found :-(</h1>" | sudo tee /var/www/html/custom_404.html
echo "<p>I have no idea where that file is, sorry.  Are you sure you typed in the correct URL?</p>" | sudo tee -a /var/www/html/custom_404.html
echo "<h1>Oops! Something went wrong...</h1>" | sudo tee /var/www/html/custom_50x.html
echo "<p>We seem to be having some technical difficulties. Hang tight.</p>" | sudo tee -a /var/www/html/custom_50x.html

Итак, теперь на сервере есть две страницы ошибок.

Настройка Apache для отображения пользовательских страниц ошибок

Теперь нужно настроить Apache для поддержки только что созданных страниц в случае возникновения соответствующей ошибки. Создайте новый конфигурационный файл в каталоге /etc/httpd/conf.d, который хранит настройки для Apache. Назовите файл custom_errors.conf:

sudo nano /etc/httpd/conf.d/custom_errors.conf

Направьте Apache на соответствующие страницы ошибок.

Для того чтобы связать каждый тип ошибки со специальной страницей ошибок, используйте директиву ErrorDocument. В целом, нужно просто указать код состояния HTTP для каждой страницы, и тогда страница появится на экране в случае возникновения указанной ошибки.

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

/etc/httpd/conf.d/custom_errors.conf
ErrorDocument 404 /custom_404.html
ErrorDocument 500 /custom_50x.html
ErrorDocument 502 /custom_50x.html
ErrorDocument 503 /custom_50x.html
ErrorDocument 504 /custom_50x.html

Этих настроек достаточно, чтобы обслуживать пользовательские страницы ошибок.

Однако рекомендуется добавить ещё один блок конфигураций, чтобы клиенты не могли запрашивать страницы ошибок напрямую. Это предотвратит путаницу (например, запрошенная напрямую страница ошибки будет сообщать пользователю об ошибке, даже если код состояния – 200 (Success)).

Чтобы настроить такое поведение веб-сервера, нужно добавить блок Files для каждой пользовательской страницы ошибок. Также нужно проверить, установлена ли переменная окружения REDIRECT_STATUS; она должна быть установлена только если директива ErrorDocument обрабатывает запрос. Если переменная окружения пуста, сервер будет обслуживать страницу 404:

/etc/httpd/conf.d/custom_errors.conf
ErrorDocument 404 /custom_404.html
ErrorDocument 500 /custom_50x.html
ErrorDocument 502 /custom_50x.html
ErrorDocument 503 /custom_50x.html
ErrorDocument 504 /custom_50x.html
<Files "custom_404.html">
<If "-z %{ENV:REDIRECT_STATUS}">
RedirectMatch 404 ^/custom_404.html$
</If>
</Files>
<Files "custom_50x.html">
<If "-z %{ENV:REDIRECT_STATUS}">
RedirectMatch 404 ^/custom_50x.html$
</If>
</Files>

Когда страницы ошибок запрашиваются клиентами, возникает ошибка 404, потому что переменная среды не установлена.

Тестирование страницы ошибок 500

Проверить работу страницы ошибок 404 очень просто: нужно запросить любой несуществующий контент. Чтобы протестировать страниц ошибок 500, нужно создать фиктивный ProxyPass.

Добавьте директиву ProxyPass в конец конфигурационного файла. Отправьте запросы для /proxytest на порт 9000 на локальной машине (на этом порте не запущено ни одного сервиса):

/etc/httpd/conf.d/custom_errors.conf
ErrorDocument 404 /custom_404.html
ErrorDocument 500 /custom_50x.html
ErrorDocument 502 /custom_50x.html
ErrorDocument 503 /custom_50x.html
ErrorDocument 504 /custom_50x.html
<Files "custom_404.html">
<If "-z %{ENV:REDIRECT_STATUS}">
RedirectMatch 404 ^/custom_404.html$
</If>
</Files>
<Files "custom_50x.html">
<If "-z %{ENV:REDIRECT_STATUS}">
RedirectMatch 404 ^/custom_50x.html$
</If>
</Files>
ProxyPass /proxytest "http://localhost:9000"

Сохраните и закройте файл.

Тестирование страниц ошибок

Проверьте конфигурационный файл на наличие ошибок:

sudo apachectl configtest

Если команда обнаружила любые ошибки, исправьте их. После этого перезапустите Apache:

sudo systemctl restart httpd

Откройте домен или IP-адрес сервера и запросите несуществующий контент, чтобы проверить работу страницы 404:

http://server_domain_or_IP/thiswillerror

На экране должна появиться страница 404:

Error 404: Not found :-(
I have no idea where that file is, sorry.  Are you sure you typed in the correct URL?

Откройте фиктивный proxypass, чтобы проверить работу страницы 500 (на экране должен появиться код состояния 503 service unavailable):

http://server_domain_or_IP/proxytest

Если всё настроено верно, на экране появится:

Oops! Something went wrong...
We seem to be having some technical difficulties. Hang tight.

После тестирования удалите фиктивную директиву из конфигураций Apache.

Заключение

Итак, теперь на сайте есть уникальные страницы ошибок. Пользовательские страницы ошибок – это отличный способ помочь посетителям понять, в чём дело, предоставить им всю необходимую информацию об ошибке и полезные ссылки (не забудьте убедиться, что ссылки работают даже в случае возникновения ошибок).

Tags: Apache, CentOS 7

Как кастомизировать стандартные страницы ошибок

Уровень сложности
Простой

Время на прочтение
6 мин

Количество просмотров 3.4K

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

Стандартный вид Ошибки 404 в Nginx

Стандартный вид Ошибки 404 в Nginx

Для упрощения процесса, я создал небольшую утилиту (прямая ссылка на проект в GitHub), по сути Node.js скрипт, которая позволяет создавать статические страницы ошибок в собственном дизайне и со своими текстовыми сообщениями. По умолчанию, утилита содержит только один шаблон в минималистичном дизайне (с поддержкой доступности и адаптивности, на сколько это возможно в такой простой странице). Но если вас не устраивает такой дизайн, то вы можете с легкостью изменить его, путем создания собственного: со своими стилями, шрифтами, изображениями и текстами.

Пример страницы для Ошибки 404

Пример страницы для Ошибки 404

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

Для упрощения интеграции, утилита автоматически создает сниппет с конфигурацией веб сервера, который легко может быть добавлен в конфигурацию вашего веб сервера. На текущий момент сниппет создается только для Nginx. Другие виды серверов будут добавлены позже (в качестве альтернативы, вы можете создать Pull Request с таким улучшениями, либо оформить Feature Request).

Использование

В базовом сценарии использования, всё что требуется, это лишь склонировать себе на компьютер репозиторий проекта, установить зависимости Node.js, запустить команду сборки, скопировать полученный результат к себе на сервер и обновить конфигурацию сервера.

$ git clone git@github.com:sapachev/error-pages.git
…
$ npm install --production
…
$ npm run build
…
INFO: Start building process
INFO: Flush build directory '/home/error-pages/dist'
INFO: Compile pages from source data:
 • /home/error-pages/dist/400.html
 • /home/error-pages/dist/401.html
 • /home/error-pages/dist/403.html
 • /home/error-pages/dist/404.html
 • /home/error-pages/dist/410.html
 • /home/error-pages/dist/500.html
 • /home/error-pages/dist/502.html
 • /home/error-pages/dist/503.html
 • /home/error-pages/dist/504.html
INFO: Compile web servers config snippets from source data:
 • /home/error-pages/dist/nginx-error-pages.conf
INFO: Build Tailwind CSS styles
INFO: Run 'INPUT="/home/error-pages/themes/minimalistic/@assets/css/main.twnd.css" OUTPUT="/home/error-pages/dist/@assets/css/main.css" npm run build:tailwind' command
INFO: Tailwind CSS styles were built
INFO: Copying assets to '/home/error-pages/dist/@assets' directory
INFO: Building process was completed in 1.727s

Продвинутое использование

В дополнение к шагам базового сценария, вы можете улучшить скомпилированные страницы меняя части, из которых они собираются: шаблоны, стили, тексты, а также сниппеты конфигурации.

Основная конфигурация утилиты хранится в файле config.json в корневой папке, которую можно менять в соответствии со своими требованиями:

{
  "tailwind": true,
  "theme": "minimalistic",
  "locale": "en"
}

Шаблоны

Все шаблоны хранятся в папке themes, где стандартной темой является minimalistic, которую можно изменить или добавить новую. Каких‑то особых требований к шаблонам страниц нет: каждый шаблон является обыкновенным HTML документом, с внедренными переменными, на месте которых будут текстовки из файлов локализации. Для обработки внедренных переменных используется библиотека mustache.js. Таким образом, если нужно реализовать какую‑то особенную логику в своих шаблонах, то вы можете ознакомиться с документацией этой библиотеки для определения имеющихся возможностей шаблонизации.

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

Стили

Стилизация шаблонов базируется на фреймворке Tailwind CSS. С помощью этого фреймворка, можно быстро описывать стили страниц без необходимости писать отдельный CSS код. Точкой входа для стилей Tailwind должен быть файл themes/<name>/@assets/css/main.twnd.css. Из него в дальнейшем будет создан файл main.css, который содержит скомпилированные и минифицированные стили. В дополнение, можно настроить Tailwind с помощью создания кастомной конфигурации, расположенной в файле theme.tailwind.config.js в корне папки с темой, и описать в ней любые опции Tailwind. Полный список опций Tailwind доступен в документации самого Tailwind.

Однако, если по каким-то причинам использование Tailwind не требуется (например, стили уже описаны ранее в CSS), компиляцию стилей Tailwind можно отключить в основной конфигурации утилиты (файл config.json). В этом случае шаг сборки стилей будет просто пропущен без какого-либо влияния на финальный результат.

Текстовые сообщения и Локализация

Все текстовые сообщения хранятся в JSON файлах, разделенных по признаку языка, и расположены в папке src. Каждая страница создается из соответствующего ей файла локализации вида <Код HTTP>.json (<Код HTTP> – это число, соответствующее коду ошибки HTTP). Таким образом, если нужно создать страницу для кода, который еще не описан, то просто создайте соответствующий JSON файл, содержащий описание этого статуса в соответствующих свойствах.

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

Для локализации страниц, просто создайте новую папку в директории src, содержащую JSON файлы с текстами страниц. Создавая JSON файлы, вы можете описать любой набор HTTP кодов (например, только для 400-ых ошибок) – просто следуйте конвенции именования, и не забывайте выделять общие тексты в файл common.json.

Конфигурации сервера

В процессе работы, Утилита автоматически создаст сниппет для вашего сервера, который будет содержать лишь те страницы, которые были созданы. Данный сниппет будет содержать настройки обрабатываемых ошибок, и указывать на страницы, которые будут их представлять. Как было сказано ранее, на данный момент только Nginx поддерживается.

Для использования полученных страниц, остается только скопировать на сервер все файлы из папки dist и включить использование сниппета в уже существующей конфигурации сервера. В соответствии с шаблоном сниппета, все страницы должны быть расположены в папке /usr/share/nginx/html/error-pages. В случае если настройки в снипетта не подходят, то вы можете отредактировать шаблон сниппета в папке snippets. Так же как и для тем оформления, шаблоны конфигураций поддерживают mustache.js, тем позволяя реализовать в шаблоне любую логику (списки, условия и т. д.).

Сам по себе конфиг, я рекомендую располагать в папке /etc/nginx/snippets/, а для его подключения использовать строчку конфигурации: include /etc/nginx/snippets/nginx-error-pages.conf;. Разумеется, это не более чем рекомендация, т.к. в реальности всё может быть иначе или сложнее.

Ниже приведен простой пример конфигурации веб‑сервера с включенным в нее сниппетом кастомных ошибок:

server {
    server_name example.com;
    access_log /var/log/nginx/example.access.log;

    include /etc/nginx/snippets/nginx-error-pages.conf;

    location / {
        root /data/www;
    }
}

Демо

Посмотреть как выглядят страницы ошибок можно на моем сайте по следующим ссылкам:

  • 400 Bad Request

  • 401 Unauthorized

  • 403 Forbidden

  • 404 Not Found

  • 410 Gone

  • 500 Internal Server Error

  • 502 Bad Gateway

  • 503 Service Unavailable

  • 504 Gateway Timeout

Сообщение об ошибках и запрос новых функций

Код утилиты нельзя назвать каким‑то сложным, однако, несмотря на этот факт, все значимые части покрыты юнит‑тестами. Впрочем, это не является гарантией отсутствия каких‑либо ошибок, поэтому если вы столкнетесь с какими‑то проблемами, то, пожалуйста, сообщите мне о них, через создание Issue в репозитории проекта: https://github.com/sapachev/error‑pages/issues

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

Участие в разработке

Проект открыт для всех желающих, и если у вас есть идеи, а главное желание и возможности их реализовать, то с радостью рассмотрю их в виде Pull Request. Со своей стороны готов предоставить вам поддержку в реализации вашей задумки. Не стесняйтесь спрашивать меня о коде, и возможных решениях вашей идеи.

Вступление

Nginx — это высокопроизводительный веб-сервер, способный предоставлять контент гибко и эффективно. При разработке ваших веб-страниц часто бывает полезно настроить каждый фрагмент контента, который увидят ваши пользователи. Это включает страницы ошибок, когда они запрашивают контент, который недоступен. В этом руководстве мы покажем, как настроить Nginx для использования пользовательских страниц ошибок в Ubuntu 14.04.

Предпосылки

Вам также необходимо установить Nginx в вашей системе. Узнайте, как настроить это, следуя th guide.

После того, как вы выполнили вышеупомянутые шаги, продолжите это руководство.

Создание пользовательских страниц ошибок

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

Мы поместим наши пользовательские страницы ошибок в каталог + / usr / share / nginx / html +, где Uginntu Nginx устанавливает корневой каталог документа по умолчанию. Мы создадим страницу для 404 ошибок, которая называется + custom_404.html +, и страницу для общих ошибок уровня 500, которая называется + custom_50x.html +. Вы можете использовать следующие строки, если вы только тестируете. В противном случае разместите свой собственный контент в следующих местах:

echo "<h1 style='color:red'>Error 404: Not found :-(</h1>" | sudo tee /usr/share/nginx/html/custom_404.html
echo "<p>I have no idea where that file is, sorry.  Are you sure you typed in the correct URL?</p>" | sudo tee -a /usr/share/nginx/html/custom_404.html
echo "<h1>Oops! Something went wrong...</h1>" | sudo tee /usr/share/nginx/html/custom_50x.html
echo "<p>We seem to be having some technical difficulties. Hang tight.</p>" | sudo tee -a /usr/share/nginx/html/custom_50x.html

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

Настройка Nginx для использования ваших страниц с ошибками

Теперь нам просто нужно сказать Nginx, что он должен использовать эти страницы всякий раз, когда возникают правильные условия ошибки. Откройте файл блока сервера в каталоге + / etc / nginx / sites-enabled +, который вы хотите настроить. Мы будем использовать файл блока сервера по умолчанию, называемый + default +, но вы должны настроить свои собственные блоки сервера, если вы используете файл не по умолчанию:

sudo nano /etc/nginx/sites-enabled/default

Теперь мы можем указать Nginx на наши пользовательские страницы ошибок.

Прямые ошибки 404 на пользовательской странице 404

Используйте директиву + error_page +, чтобы при возникновении ошибки 404 (когда запрошенный файл не был найден), созданная вами пользовательская страница обслуживалась. Мы создадим блок местоположения для файла, где мы сможем убедиться, что корень соответствует расположению нашей файловой системы и что файл доступен только через внутренние перенаправления Nginx (не запрашиваемые напрямую клиентами):

/ И т.д. / Nginx / сайты с поддержкой / по умолчанию

server {
       listen 80 default_server;
       listen [::]:80 default_server ipv6only=on;

       . . .






}

Обычно нам не нужно устанавливать + root + в новом блоке местоположения, поскольку он совпадает с корнем в блоке сервера. Тем не менее, мы здесь явно, так что наши страницы ошибок обслуживаются, даже если мы перемещаем наш обычный веб-контент и корень связанного документа в другое место.

Направляйте ошибки 500 уровней на пользовательскую страницу 50x

Затем мы можем добавить директивы, чтобы гарантировать, что когда Nginx обнаружит ошибки 500-го уровня (проблемы, связанные с сервером), он будет обслуживать другую пользовательскую страницу, которую мы создали. Это будет следовать той же формуле, которую мы использовали в предыдущем разделе. На этот раз мы устанавливаем несколько ошибок уровня 500 для всех, используя страницу + custom_50x.html +:

/ И т.д. / Nginx / сайты с поддержкой / по умолчанию

server {
       listen 80 default_server;
       listen [::]:80 default_server ipv6only=on;

       . . .

       error_page 404 /custom_404.html;
       location = /custom_404.html {
               root /usr/share/nginx/html;
               internal;
       }










}

Внизу мы также добавили фиктивный проход FastCGI, чтобы мы могли протестировать нашу страницу ошибок на 500 уровнях. Это не будет работать правильно, так как сервер не существует. Запрос страницы здесь позволит нам проверить, что 500-уровневые ошибки обслуживают нашу пользовательскую страницу.

Сохраните и закройте файл, когда вы закончите.

Перезапуск Nginx и тестирование ваших страниц

Проверьте синтаксис файла конфигурации, набрав:

Если были обнаружены какие-либо ошибки, исправьте их, прежде чем продолжить. Когда синтаксические ошибки не возвращаются, перезапустите Nginx, набрав:

sudo service nginx restart

Теперь, когда вы переходите на домен или IP-адрес вашего сервера и запрашиваете несуществующий файл, вы должны увидеть страницу 404, которую мы настроили:

изображение: https: //assets.digitalocean.com/articles/nginx_custom_error_1404/custom_404.png [нестандартный 404 nginx]

Когда вы перейдете в место, которое мы настроили для прохода FastCGI, мы получим ошибку 502 Bad Gateway с нашей пользовательской страницей на 500 уровней:

изображение: https: //assets.digitalocean.com/articles/nginx_custom_error_1404/custom_50x.png [пользовательский 50x nginx]

Теперь вы можете вернуться и удалить поддельное местоположение прохода FastCGI из вашей конфигурации Nginx.

Заключение

Теперь вы должны обслуживать пользовательские страницы ошибок для вашего сайта. Это простой способ персонализировать опыт ваших пользователей, даже если они испытывают проблемы. Одним из предложений для этих страниц является включение ссылок на места, куда они могут обратиться за помощью или дополнительной информацией. Если вы сделаете это, убедитесь, что ссылки назначения доступны даже при возникновении связанных ошибок.

Понравилась статья? Поделить с друзьями:
  • Урок 147 работа над ошибками
  • Уровнем значимости называется вероятность совершить ошибку первого рода
  • Урм ошибка загрузки заголовка при обновлении
  • Урм ошибка 5000
  • Урм ас бюджет ошибка извлечения пакета