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

Файл htaccess

От автора: в этом уроке мы с вами познакомимся еще с двумя полезными директивами сервера, которые можно использовать в файле htaccess.

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

скачать исходникискачать урок

Иногда на сайте, написанном исключительно на HTML, может возникнуть необходимость вставки кода PHP. Но, как Вы знаете, файлы с расширением html сервер сразу же отдает клиенту и программный код в этих файлах никак не обрабатывается.

Профессия PHP-разработчик с нуля до PRO

Готовим PHP-разработчиков с нуля

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

Узнать подробнее

Командная стажировка под руководством тимлида

90 000 рублей средняя зарплата PHP-разработчика

3 проекта в портфолио для старта карьеры

Другое дело файлы php. Здесь правильно настроенный сервер ни за что не отдаст просто так такой файл. Прежде всего, сервер отдает этот файл интерпретатору PHP, который, в свою очередь, обрабатывает файл, выполняя программный код в файле. Затем интерпретатор возвращает уже обработанный документ серверу, который отдает его уже клиенту.

Как же нам «заставить» сервер отдавать, к примеру, файлы html интерпретатору для исполнения программного кода? В этом нам как раз и поможет следующая директива:

# выполнение кода PHP в файлах не .php

AddType application/xhttpdphp .html .htm .txt .css

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

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

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

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

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

Указать серверу на собственные страницы ошибок можно с помощью директивы ErrorDocument, после которой мы укажем код ошибки и путь к странице ошибки, которую нужно показать в случае данной ошибки:

# страницы ошибок

#ErrorDocument 403 «Access Denied»

ErrorDocument 403 /htaccess/page403.html

ErrorDocument 404 //localhost/htaccess/page404.html

Здесь, как Вы могли заметить, мы можем использовать как относительный, так и абсолютный путь. Также, как вариант, можно вместо страницы показать какой-нибудь текст (хотя в этом мало смысла).

Профессия PHP-разработчик с нуля до PRO

Готовим PHP-разработчиков с нуля

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

Узнать подробнее

Командная стажировка под руководством тимлида

90 000 рублей средняя зарплата PHP-разработчика

3 проекта в портфолио для старта карьеры

На этом текущий урок завершен. Удачи и до встречи в следующем!

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

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

  • выдать клиенту простое жестко закодированное сообщение об ошибках;
  • выдать настроенное сообщение;
  • перенаправить(redirect) запрос локальному URL, чтобы обработать проблему/ошибку;
  • перенаправить(redirect) запрос внешнему URL, чтобы обработать проблему/ошибку.

Первое действие выполняется по умолчанию, в то время как действия 2-4 должны быть сконфигурированы директивой ErrorDocument, которая сопровождается HTTP-кодом_ответа и сообщением или URL.

Сообщения в этом контексте начинаются с одиночной кавычки («), которая не включается в сообщение непосредственно. Apache будет иногда предлагать дополнительную информацию относительно проблемы/ошибки.

URLs может начинаться с наклонной черты вправо (/) для локального URLs, или быть полным URL, который поможет пользователю решить проблему.

Все данные диррективы прописываются в файле .htaccess

.htaccess (от. англ. hypertext access) — файл дополнительной конфигурации веб-сервера Apache, а также подобных ему серверов. Позволяет задавать большое количество дополнительных параметров и разрешений для работы веб-сервера в отдельных каталогах (папках), таких как управляемый доступ к каталогам, переназначение типов файлов и т.д., без изменения главного конфигурационного файла.

Синтаксис:

ErrorDocument код-ошибки документ

Пример:

ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Извините, сегодня доступ Вам закрыт

Обратите внимание, что, когда Вы определяете ErrorDocument, который указывает на удаленный URL (то есть что-нибудь с методом типа «http» в начале) Apache пошлет переназначающий ответ пользователю, чтобы сообщить ему, где найти нужный документ, даже если документ находиться на том же самом сервере. За этим следуют некоторые особенности, наиболее важной является та, что если Вы используете директиву «ErrorDocument 401», то она должна ссылаться на локальный документ. Это обусловлено характером HTTP базисной опознавательной схемы.

.htaccess — файл дополнительной конфигурации веб-сервера Apache. Он является подобием httpd.conf с той разницей, что действует только на каталог, в котором располагается, и на его дочерние каталоги.

Файл .htaccess может быть размещён в любом каталоге. Директивы этого файла действуют на все файлы в текущем каталоге и во всех его подкаталогах (если эти директивы не переопределены директивами нижележащих файлов .htaccess)

В этой статье мы приведём несколько примеров использования данного файла.

Собственные страницы об ошибках

Иногда возникает необходимость (например, исходя из эстетических соображений и дизайна сайта) отображать собственные страницы вместо стандартных страниц ошибок веб-сервера (404 Not Found и им подобные). Это можно осуществить через файл .htaccess:

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

2. В файл .htaccess добавьте строку:

ErrorDocument 404 /404.html

где domain.tld — имя Вашего домена

3. Аналогично следует делать и для других кодов ошибок. Например, для ошибки 500 директива должна быть:

ErrorDocument 500 http://domain.tld/500.html

Наиболее распространённые коды ошибок:

401 — требуется авторизация
400 — неверный запрос
403 — доступ запрещён
500 — внутренняя ошибка сервера
404 — страница не найдена

Запрещение листинга директории

Иногда, по тем или иным причинам, может возникнуть ситуация, когда в директории нет index файла. Например, директория служит хранилищем файлов. При запросе к подобной директории Apache будет отображать список всех файлов, которые в ней находятся. Чтобы запретить листинг, создайте в подобной директории файл .htaccess и добавьте в него строку:

Options -Indexes

Запрещение доступа по IP

Чтобы запретить доступ по HTTP (данная опция касается только HTTP протокола) к директории c определённого IP, создайте в этой директории файл .htaccess и добавьте в него строку:

Deny from xx.xx.xx.xx

где xx.xx.xx.xx — IP адрес, с которого следует запретить доступ

Также Вы можете запретить доступ для всех:

Deny from all

Запрещение доступа к определенному файлу

Чтобы запретить доступ по HTTP (данная опция касается только HTTP протокола) к директории c определённого IP, создайте в этой директории файл .htaccess и добавьте в него блок:

<Files «file.php»>

Order Deny,Allow

Deny from all

Allow from xxx.xxx.xxx.xxx

</Files>

Где file.php — название файла к которому нужно ограничить доступ, а xxх.xxх.xxх.xxх — IP адрес, с которого следует разрешить доступ к указанному файлу.

Альтернативные index файлы

Если Вы хотите, чтобы индексными файлами были не только index.html, index.htm и index.php, Вы можете указать собственные имена для подобных файлов с помощью директивы DirectoryIndex, например:

DirectoryIndex index.php index.html index.htm index.shtml default.php my.php

Перенаправления (редиректы)

Если Вы хотите установить редирект для определённого URL Вашего сайта, подобное также возможно сделать с помощью .htaccess, например:

Redirect /admin/passwd.php http://www.site.ru/denied.html

Если разместить файл .htaccess с подобной директивой в корне Вашего сайта, при запросе страницы http://ваш-сайт.ру/admin/passwd.php будет осуществлено перенаправление на http://www.site.ru/denied.html

Перенаправление возможно делать как для файлов, так и для целых директорий, например:

Redirect /admin/ http://www.site.ru/denied.html

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

Защита директорий паролем

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

AuthName «Section Name»
AuthType Basic
AuthUserFile /full/path/to/.htpasswd
Require valid-user

где:

AuthName — заглавие окна для ввода логина/пароля, которое откроет броузер при запросе данной директории

AuthType — тип аутентификации. В данном случае Basic.

AuthUserFile — полный путь к файлу паролей

Require — требования для успешной аутентификации. В данном случае требуются валидные имя пользователя и пароль.

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

Генератор htpasswd

.htpasswd строка

username:encryptedWithSalt

Более детально о всех директивах .htaccess Вы можете узнать на сайте разработчиков Apache: http://httpd.apache.org/docs/2.2/howto/htaccess.html

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

Для начала немного теории. Всё, что написано ниже, справедливо для сервера Apache (их в интернете подавляющее большинство). Когда вы набираете в строке несуществующий адрес или переходите по «битой ссылке», на страничке высвечивается жирными буквами сообщение «Not found» — «документ не найден», хотя вкупе с устрашающим видом надписи может быть переведено неопытным пользователем как «пошёл вон» :). Кстати, пользователи IE возможно и не видели эту страничку ни разу, поскольку он – IE – формирует в этом случае своё сообщение с «дружественным» содержанием, типа «обновите страничку, позвоните другу, который вам эту ссылочку дал…», но это делу не помогает. Иногда IE может и показать оригинальное сообщение сервера, но только в том случае, если оно больше определённого размера (по умолчанию 512 байт). В общем, итог всегда один – страницы нет и посетитель недоволен. А нам, администраторам сайтов, надо заботиться, чтобы эта потеря была менее болезненной.

Давайте разберёмся, что происходит на сервере при запросе правильных/ошибочных URL.

При GET-запросе URL (тот, что в адресной строке браузера) передаётся серверу, а на выходе клиенту выдаётся набор заголовков с последующим полем данных. Заголовки никогда не выводятся пользователю напрямую и содержат много служебной информации, которая может быть обработан CGI-скриптами (а это нам скоро и понадобится). Среди этих заголовков всегда есть так называемые коды ответов. Если не вдаваться в подробности, то они передаются примерно так:

GET /index.htm
HTTP/1.1 404 Not Found

Первая строка говорит о том, что пользователем (точнее, браузером пользователя) был передан запрос на страницу index.htm, а вторая строка сообщает ему, что такой документ не найден, после чего следует блок данных — HTML-страница с сообщением об ошибке. Если URL правильный, всё происходит так, как и должно быть – передаётся код ответа 200 и запрошенный файл. Код ответа 200 передаётся всегда при удачном запросе, но мы его никогда не видим. Как уже говорилось, при неудачном запросе сервер сгенерирует код ответа в диапазоне 400…499 и мы увидим стандартное сообщение об ошибке, которое, огорчает пользователя и портит репутацию сайта. Вообще говоря, у хорошего веб-мастера таких ошибок на сайте быть не должно, но не его вина, что например пользователь вдруг сказал «принеси то, не знаю что».

Перейдём от рассуждений к делу. У сервера Apache имеется стандартная директива обработки ошибок ErrorDocument, которая сопоставляет коду ошибки адрес документа, который будет показан пользователю. Обычно перенаправление устанавливают на документ, содержащий логотип сайта и краткую информацию «что делать». Увидев такую страницу вместо стандартного сообщения на fatal.ru (два года назад, когда начал заниматься веб-программированием), я долго был под впечатлением! Откуда они знают, что у меня такой страницы нет? :) Формат директивы такой:

ErrorDocument 400 400.html

В случае ошибки 400 пользователю выдаётся файл 400.html – всё очень просто и удобно. Сразу же отметим, что можно использовать четыре варианта передачи сообщения об ошибке:

ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Доступ запрещён

В последнем случае вместо файла пользователь увидит на экране сообщение, следующее за одиночной кавычкой (закрывать кавычку не следует!).

Прописать директиву можно в двух местах – конфигурационном файле Apache httpd.conf или в файле управления доступом к директориям .htaccess. В первом случае вы должны иметь доступ к httpd.conf, а для этого вы должны являться администратором сервера (и, скорее всего, вам эта статья не понадобилась бы :) или пользователем хостинга — во втором случае. Причём на хостинге должно быть включено редактирование .htaccess самим пользователем (это позволяют все платные и почти все бесплатные службы хостинга). Кроме того, на платных серверах часто установлена панель управления сайтом cPanel. Так вот там можно самому создавать и редактировать страницы ошибок на основе SSI, даже если вы не специалист.

Короче, создаём в корне своего сайта файлик .htaccess и записываем в него строчку «ErrorDocument 400 400.html«, при условии, что файл 400.html уже существует.

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

  1. Самый простой вариант – набросать в HTML-редакторе или «Блокноте» обычную страничку без графического оформления и сохранить её под нужным именем.
  2. Вариант посложнее – можно добавить в этот HTML-файл директивы SSI, которые, к примеру, будут показывать URL, адрес, с которого пришёл пользователь, время, подключить внешние файлы и т.д.
  3. Но согласитесь, первые два варианта – это примитив, не достойный настоящего веб-мастера. Опытные программисты пишут страницы ошибок на PHP. В этом есть одно достоинство – мы получаем доступ к переменным окружения, что даёт возможность лучше анализировать ошибочную ситуацию, выводить больше информации пользователю, вести лог ошибок в файле или базе данных, а не тупо выводить Not found и посылать бедного юзера на главную страницу.

Как вы уже догадались, мы будем рассматривать именно третий вариант. Начнём с простого – как PHP-скрипт получит код ошибки? Естественно, через параметр. Например, вот так:

error.php?400

В самом скрипте код ошибки после знака вопроса будет доступен в переменной $argv[0]. Теперь проверим скрипт (он должен вывести код ошибки, указанный после «?»):


<?php

echo $argv[0];

?>



Можно было бы передать параметр в классическом виде error.php?id=400, но так проще и безопаснее — этот скрипт принимает только одну переменную, зачем лишние лазейки? Сразу же обезопасим скрипт от ввода неверных данных: приведём код к целому типу и сделаем присвоение кода 404 по умолчанию, если скрипт был вызван без параметров. Приучайте себя к написанию безопасного кода! Теперь даже если ввести error.php?404abc или даже error.php?abc – значение переменной $id (она введена для читабельности) всё равно будет равно 404.


<?php
// проверяем переменную

$id = $argv[0];

$id = abs(intval($id));

if (!$id) $id = 404;

echo
$id;
?>



Следующее, что мы сделаем – сопоставим коду русскоязычное описание. Это можно сделать при помощи операторов switch…case, но опытный программист сделает это более аккуратно и красиво – через ассоциативный массив, в котором ключ – это код ошибки, а значение – это её описание. Сделать такой массив очень просто, да и дополнять его легче, чем списки switch…case. Рекомендую начинающим программистам всегда использовать ассоциативный массив вместо switch…case, если в списке больше трёх позиций – выигрыш в скорости, размере кода и понятности. Список кодов ошибок можно найти на официальном сайте W3C (организация по веб-стандартам) http://www.w3.org/Protocols/HTTP/HTRESP.html или в любой книге по веб-программированию. Я сделал так:


<?php
// проверяем переменную

$id = $argv[0];

$id = abs(intval($id));

if (!$id) $id = 404;
// ассоциативный массив кодов и описаний

$a[401] = "Требуется авторизация";

$a[403] = "Пользователь не прошел аутентификацию, доступ запрещен";

$a[404] = "Документ не найден";

$a[500] = "Внутренняя ошибка сервера";

$a[400] = "Неправильный запрос";
// выводим код и описание

echo "$id $a[$id]";
?>



В результате выполнения этого кода пользователь увидит сообщение «404 Документ не найден» (по-крайней мере, так вывелось у меня, вы можете смоделировать другую ошибку). В принципе, тот же результат можно было получить при использовании первого способа, но разве я сказал, что мы на этом остановимся?

Кстати, пока не забыл. Ошибки с кодами 500…599 встречаются обычно, когда ошибку совершает сценарий, расположенный на вашем сервере. Некоторые интерпретаторы сценариев, например PHP, никогда не допускают такой ошибки. Если в вашем PHP-скрипте есть ошибка, интерпретатор сам выведет ошибочное сообщение с указанием её происхождения, а не просто «Ошибка». Со стороны сервера это будет выглядеть как нормальный ответ клиенту, поэтому ошибка 500 при использовании PHP у вас практически никогда не возникнет. В отличие от него, Perl генерирует ошибку 500 и записывает сообщение о ней в лог сервера. Иди потом, разбери его – сложность отладки Perl-скриптов очень высокая. Это была одна из причин, по которой мне в своё время посоветовали перейти с Perl на PHP, что я и сделал, чего и вам желаю.

Вернёмся к написанию скрипта. Основная часть – обработка кода ошибки – уже готова, займёмся «довесками». Для начала выведем поясняющее сообщение с ошибочным URL:


echo "Запрошенный Вами URL: <b>http://$SERVER_NAME$REQUEST_URI</b><br /> ";

Здесь включены две глобальные переменные $SERVER_NAME и $REQUEST_URI. Первая содержит имя сервера, вторая – URI (не путать с URL), который был запрошен. Выведем ещё на всякий случай IP-адрес, название браузера и текущее время на сервере.


$time = date("d.m.Y H:i:s");

Ваш IP: <b>$REMOTE_ADDR</b><br />

Ваш браузер: <b>$HTTP_USER_AGENT</b><br />

Текущее время сервера: <b>$time</b><br />


Согласитесь, это уже намного интересней. Если пользователь пришёл на ошибку по ссылке с другой страницы, покажем ему и этот URL этой страницы (переменная $HTTP_REFERER). Дополнительно можно показать реальный IP-адрес клиента, если он работает через прокси (переменная $HTTP_X_FORWARDER_FOR).


if ($HTTP_REFERER) $body .= "Вы пришли со страницы: <b>$HTTP_REFERER</b><br />n";

if ($HTTP_X_FORWARDER_FOR) $body .= "Ваш IP через прокси: <b>$HTTP_X_FORWARDER_FOR</b><br />n";


Ну и в завершение в самом низу «подпись» сервера (не на всех хостингах она работает корректно, потому что это чисто «серверная» переменная):


$_SERVER['SERVER_SIGNATURE']

Думаю, этой информации будет достаточно, для того чтобы пользователь не почувствовал, что пришёл на «последнюю страницу интернета». Но есть ещё одна деталь, которую не упустит внимательный программист. Вспомните, откуда вы чаще всего попадаете на «ошибочные страницы»? Ну конечно из поисковых систем, в которых информация быстро устаревает. В подавляющем большинстве случаев мелкие проекты, типа FoxWeb переезжают с сервера на сервер, а потом на новом сервере сайт модернизируется, а старый остаётся на старом месте. Ну, в общем вы меня поняли :). У меня было так: первый сайт был открыт на kiiut.fatal.ru, потом всё его содержимое было скопировано на foxweb.net.ru. В поисковых системах хранятся ссылки на оба сайта. Через какое-то время старое содержимое на foxweb было удалено, а ссылки на него остались в поисковиках. Если заменить адрес сервера в ошибочной ссылке, то она вполне будет работать. Поясню на примере.

Предположим, человек нашёл в поисковой системе что-то вроде http://foxweb.net.ru/catalog/sbornik_fox1.html. У нашего сервера такой ссылки нет, но она должна была остаться на старом сервере со старым содержимым. Тогда предложим пользователю перейти по адресу http://kiiut.fatal.ru/catalog/sbornik_fox1.html. Опишем эту особенность в программе:


Возможно интересующую Вас информацию можно найти по старому адресу:<br />

<a href="http://kiiut.fatal.ru$REQUEST_URI" target="_blank"><b>http://kiiut.fatal.ru$REQUEST_URI</b></a><br />


Даже если у вас не было такой ситуации, как у меня, возможно вы переписывали скрипты и адреса поменялись. Например, http://someserver.ru/catalog/ заменим на http://someserver.ru/?catalog или http://someserver.ru/cgi-bin/catalog.cgi. Надеюсь, общий смысл вам понятен, главное знать, что чем заменять.

Есть ещё одна особенность применения ошибочных страниц. Если несуществующая страница вызвана через вложенные директории, а заменяющая страница (наш скрипт) лежит в корне, то картинки на ней не будут отображены, а ссылки не будут работать. Почему? Это произойдёт в том случае, если вы используете на своём сайте относительные пути. Приведу пример:

http://someserver.ru/dir1/dir2/dir3/ — ошибочный адрес.
http://someserver.ru/error.php?404 – заменяющая страница будет вызвана по ОШИБОЧНОМУ ПУТИ, так как будто она там и хранится! Тогда ссылки на ней типа «page1.html» будут реально приводить вас по адресу http://someserver.ru/dir1/dir2/dir3/page1.html что будет вызывать ещё большее количество ошибок. Излечиться от этого можно, используя абсолютные пути ссылок и картинок (с именем сервера) или ставить перед относительным путём знак «/«, что на большинстве серверов указывает на корневую директорию сайта. Заметьте, что знак «./» будет указывать на текущую директорию.

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

Фрагмент файла http.conf или .htaccess для правильной обработки ошибок:

ErrorDocument 400 /error.php?400
ErrorDocument 401 /error.php?401
ErrorDocument 403 /error.php?403
ErrorDocument 404 /error.php?404
ErrorDocument 500 /error.php?500

Текст скрипта error.php:

<?php

$id

= $argv[0];

$id = abs(intval($id));

if (!
$id) $id = 404;
// ассоциативный массив кодов и описаний

$a[401] = "Требуется авторизация";

$a[403] = "Пользователь не прошел аутентификацию, доступ запрещен";

$a[404] = "Документ не найден";

$a[500] = "Внутренняя ошибка сервера";

$a[400] = "Неправильный запрос";
// определяем дату и время в стандартном формате

$time = date("d.m.Y H:i:s");

// эта переменная содержит тело сообщения

$body =<<<END
Запрошенный Вами URL: <b>http://$SERVER_NAME$REQUEST_URI</b><br />

Возможно интересующую Вас информацию можно найти по старому адресу:<br />

<a href="http://kiiut.fatal.ru$REQUEST_URI" target="_blank"><b>http://kiiut.fatal.ru$REQUEST_URI</b></a><br />

<br />

Ваш IP: <b>$REMOTE_ADDR</b><br />

Ваш браузер: <b>$HTTP_USER_AGENT</b><br />

Текущее время сервера: <b>$time</b><br />

END;
if (
$HTTP_REFERER) $body .= "Вы пришли со страницы: <b>$HTTP_REFERER</b><br />n";

if (
$HTTP_X_FORWARDER_FOR) $body .= "Ваш IP через прокси: <b>$HTTP_X_FORWARDER_FOR</b><br />n";

?>

<h1><i><?=$id?></i> <?=$a[$id]?></h1>

<p><?=$body?></p>

<?=$GLOBALS['SERVER_SIGNATURE']?>

Желаю всем удачного программирования и 200-го кода!

P.S. — Мой сайт ещё совсем зелёный, но там много интересного заходите в гости!

7 июня, 2022 12:03 пп
938 views
| Комментариев нет

LEMP Stack, Ubuntu

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

Требования

  • Виртуальный сервер с пользователем sudo (мы используем сервер Ubuntu 22.04, настроенный по этому мануалу).
  • Предварительно установленный веб-сервер Nginx (инструкции по установке вы найдете здесь).

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

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

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

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

Сначала создайте HTML-файл для своей пользовательской страницы 404 с помощью nano или другого текстового редактора:

sudo nano /usr/share/nginx/html/custom_404.html

Вставьте туда код, который определяет пользовательскую страницу:

<h1 style='color:red'>Error 404: Not found :-(</h1>
<p>I have no idea where that file is, sorry. Are you sure you typed in the correct URL?</p>

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

Теперь создайте файл HTML для страницы 500:

sudo nano /usr/share/nginx/html/custom_50x.html

Вставьте в файл следующее:

<h1>Oops! Something went wrong...</h1>
<p>We seem to be having some technical difficulties. Hang tight.</p>

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

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

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

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

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

Теперь нужно направить Nginx на соответствующие страницы.

Настройка пользовательской страницы 404

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

server {
    listen 80 default_server;



    . . .

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

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

Настройка страницы ошибок 50х

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

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

Отредактируйте файл /etc/nginx/sites-enabled/default следующим образом:

server {
    listen 80 default_server;


    . . .

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

    error_page 500 502 503 504 /custom_50x.html;
    location = /custom_50x.html {
        root /usr/share/nginx/html;
        internal;
    }

    location /testing {
        fastcgi_pass unix:/does/not/exist;
    }
}

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

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

Чтобы проверить синтаксис ваших файлов, введите:

sudo nginx -t

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

sudo systemctl restart nginx

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

http://server_domain_or_IP/thiswillerror

Перейдите в расположение вашего FastCGI и вы получите ошибку 502 Bad Gateway, что является ошибкой уровня 50х:

http://server_domain_or_IP/testing

Вернитесь в конфигурационный файл и удалите фиктивный FastCGI.

Заключение

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

Tags: NGINX, Ubuntu 22.04

Понравилась статья? Поделить с друзьями:
  • Снять ошибку лансер 10
  • Снять ошибку бош серия 6
  • Снять ошибку аирбэг
  • Снять ошибку абс ниссан примера р12
  • Снять ошибку f21 на стиральной машине бош