На сервере в корне находятся различные файлы — открыты для просмотра и скачивания, что то наподобие файлопомойки.
Создана папка в корне сервера /var/www/1/, а в ней пустой файл с названием «test».
Так же туда помещён пустой .htaccess
Вопрос в том как мне вызвать ошибку 500 — internal server error в клиенте, при попытке зайти:
site.ru/1 и site.ru/1/test
Настройки Апач:
<Directory /var/www/>
#Options Indexes FollowSymLinks
Options Indexes
AllowOverride None
Require all granted
</Directory>
....
<Directory /var/www/1/>
AllowOverride All
Order allow,deny
Allow from all
</Directory>You may use the following function to send a status change:
function header_status($statusCode) {
static $status_codes = null;
if ($status_codes === null) {
$status_codes = array (
100 => 'Continue',
101 => 'Switching Protocols',
102 => 'Processing',
200 => 'OK',
201 => 'Created',
202 => 'Accepted',
203 => 'Non-Authoritative Information',
204 => 'No Content',
205 => 'Reset Content',
206 => 'Partial Content',
207 => 'Multi-Status',
300 => 'Multiple Choices',
301 => 'Moved Permanently',
302 => 'Found',
303 => 'See Other',
304 => 'Not Modified',
305 => 'Use Proxy',
307 => 'Temporary Redirect',
400 => 'Bad Request',
401 => 'Unauthorized',
402 => 'Payment Required',
403 => 'Forbidden',
404 => 'Not Found',
405 => 'Method Not Allowed',
406 => 'Not Acceptable',
407 => 'Proxy Authentication Required',
408 => 'Request Timeout',
409 => 'Conflict',
410 => 'Gone',
411 => 'Length Required',
412 => 'Precondition Failed',
413 => 'Request Entity Too Large',
414 => 'Request-URI Too Long',
415 => 'Unsupported Media Type',
416 => 'Requested Range Not Satisfiable',
417 => 'Expectation Failed',
422 => 'Unprocessable Entity',
423 => 'Locked',
424 => 'Failed Dependency',
426 => 'Upgrade Required',
500 => 'Internal Server Error',
501 => 'Not Implemented',
502 => 'Bad Gateway',
503 => 'Service Unavailable',
504 => 'Gateway Timeout',
505 => 'HTTP Version Not Supported',
506 => 'Variant Also Negotiates',
507 => 'Insufficient Storage',
509 => 'Bandwidth Limit Exceeded',
510 => 'Not Extended'
);
}
if ($status_codes[$statusCode] !== null) {
$status_string = $statusCode . ' ' . $status_codes[$statusCode];
header($_SERVER['SERVER_PROTOCOL'] . ' ' . $status_string, true, $statusCode);
}
}
You may use it as such:
<?php
header_status(500);
if (that_happened) {
die("that happened")
}
if (something_else_happened) {
die("something else happened")
}
update_database();
header_status(200);
I know this is an old thread, but when I searched on Google, it jumps out as the first answer. I was trying to figure out how to do it these days, so I think I should post my workaround from 2018.
As you all have known, no, you cannot simply trigger Apache’s error pages from PHP. There’s no way doing it. So the best workaround I could find, after some research, is to use a PHP function to display the custom error pages, which is called from both what you specified in Apache, and the page that you want to trigger 500 Internal Server Error.
Here is my conf of Apache:
ErrorDocument 400 /error.php
ErrorDocument 401 /error.php
ErrorDocument 403 /error.php
ErrorDocument 404 /error.php
ErrorDocument 500 /error.php
As you could see, all 4xx and 500 errors are redirected to a same php file. Why I’m not using separate files for each code is another question, which has nothing to do with your question here, so let’s forget it and focus on error.php for now.
Here are some lines of error.php:
<?php
require_once("error_page.php");
$relative_path = "";
$internal_server_error = FALSE;
if (isset($_SERVER['REDIRECT_URL']) && $_SERVER['REDIRECT_URL'] != "")
{
$relative_path = $_SERVER['REDIRECT_URL'];
$internal_server_error = (http_response_code() >= 500);
}
else if (isset($_SERVER['REQUEST_URI']))
{
$relative_path = $_SERVER['REQUEST_URI'];
}
ErrorPage::GenerateErrorPage($internal_server_error, $relative_path);
?>
In short, it receives HTTP status code from Apache via http_response_code(), and simply categorize the status code into two categories: Internal Server Error and Non-Internal Server Error. It then passes the category to ErrorPage::GenerateErrorPage() which actually generates contents of the error page.
In ErrorPage::GenerateErrorPage(), I do something like this:
<?php
http_response_code($internal_server_error ? 500 : 404);
?>
at the beginning of the function, so that there won’t be any annoying “headers already sent”. This function will generate a fully functional error page with correct (or what we expected, at least) HTTP status code. After setting the HTTP status code, as you may guess, one of two prepared contents will be generated by following php codes, one for 500, another for 404.
Now let’s go back to your question.
You want to trigger exactly the same error page as Apache does, and now you can simply call the ErrorPage::GenerateErrorPage() from wherever you want, as long as you give it correct parameters (TRUE for 500, FALSE for 404 in my case).
Obviously, because that the Apache error pages are generated by the same function ErrorPage::GenerateErrorPage(), we can guarantee that what you trigger wherever is exactly what you would expect from Apache error pages.
Here is my example of a trigger page:
<?php
ob_start();
require_once("error_page.php");
try
{
// Actual contents go here
phpInfo();
throw new Exception('test exception');
}
catch (Exception $e)
{
ob_clean();
ErrorPage::GenerateErrorPage(TRUE);
ob_end_flush();
exit();
}
ob_end_flush();
?>
The reason I use ob_start() and ob_clean() is that, in this way, I can clear anything output before the exception occurs, and send a pure 500 Internal Server Error page that looks exactly the same as Apache gives, without any content on the trigger page (phpInfo() in this case). ob_start() and ob_clean() also make sure that there won’t be “headers already sent”, because nothing will ever be sent unless you call ob_end_flush().
The solution above is concluded from what I researched these days. It is so far so good for me, but I’m not sure if it is the correct way to do it. Any comments, questions, thoughts, suggestions and improvements are welcomed.
- Предыдующая статья: Делаем собственную страницу ошибки 404
2019-12-01
Здравствуйте, уважаемый посетитель!
Сегодня в рамах рассмотрения системы обработки ошибок выполним необходимые действия по выводу пользователю сообщения о возникновении внутренней ошибки сервера Internal Server Error, соответствующей статусу HTTP 500.
Это необходимо сделать, так как никто не застрахован от возникновения подобных проблем. В таких случаях, если не предпринять соответстующих мер, пользователь в своем браузере будет видеть только лишь какой-нибудь ущербный, неполноценный вариант веб-страницы. Либо вообще пустой экран или страницу в несколько строк с непонятными для него техническими терминами.
И вот для того, чтобы упорядочить работу сайта, обеспечивая пользователя при любых ситуациях необходимой информацией, мы создадим собственную страницу 500.
А затем, для обеспечения на нее перенаправления, сформируем пользовательский обработчик фатальных ошибок PHP. Который в дальнейшем поможет нам обеспечить и другие возможности создаваемого механизма, такие как сохранение логов и отправка сообщений по email.
- Создание страницы 500
- Перехват и обработка фатальных ошибок PHP
- Буферизация вывода в PHP
- Дополнение файла .htaccess
- Проверка работы сайта при внутренней ошибке сервера
- Исходные файлы сайта
Создание страницы 500
В первую очередь создадим в корне сайта новый файл с соответствующим именем, например «page_500.php». И поместим в него код страницы, которая будет отображаться при возникновении ошибки 500. А выполним это аналогично тому, как мы это делали в предыдущей статье при создании страницы 404.
Правда, сделаем это с некоторым отличием, заключающимся в том, что в этот раз при ее формировании будем использовать только разметку HTML, исключая какое-либо использование PHP.
Ведь не логично применять фрагменты кода, которые в случае возникновения фатальной ошибки PHP могут повлиять на отправку страницы, предназначенную, как раз, для обработки таких нестандартных ситуаций.
Конечно, это не относится к применению функции header(), с помощью которой отправляется HTTP заголовок с кодом 500, соответствующий внутренней ошибки сервера (строка 2 в приведенном ниже коде).
kak-vyvesti-stranicu-oshibki-500_1
Рис.1 Файл «page_500.php» с HTML-кодом страницы 500
Как видно, данный вариант по структуре полностью соответствует предыдущей странице 404, но выполнен на чистом HTML. Причем все общие блоки: шапка, меню, основное содержание и футер включены непосредственно, без применения подключающих инструкций PHP.
Что касается оформления, то в данном случае этого не требуется, так HTML-код страницы мало чем отличается от предыдущей. И как следствие, все необходимые свойства уже ранее назначены и добавлены в таблицу стилей CSS.
И в этом можно убедиться, если сейчас открыть созданную страницу через адресную строку браузера, добавив к доменному имени ее адрес /page_500.php. Как и в предыдущем случае в начале сделаем это в обычном, десктопном варианте пользовательского устройства.
Рис.2 Вид созданной страницы 500
А теперь посмотрим как это будет выглядеть при малом разрешении экрана в одно колоночном исполнении.
Рис.3 Вид страницы 500 при малом разрешении экрана
Как видно, полученная страница по форме схожа с предыдущей 404. За исключением содержания, отражающего теперь информацию о возникновении внутренней ошибки сервера, соответствующей статусу 500 протокола HTTP.
Таким образом необходимая страница создана. И теперь осталось только обеспечить на нее перенаправление.
Перехват и обработка фатальных ошибок PHP
Как ранее отмечалось, внутренняя ошибка сервера наиболее часто возникает в следствии фатальных ошибок PHP. Причем такие случаи обычно сопровождаются остановкой скрипта. Отчего идентифицировать такую ошибку с помощью того же самого скрипта не получится. Так как в этом случае выполнение в нем каких-либо последующих действий не представляется возможным.
Как вариант решения этой проблемы — применение встроенной функции обратного вызова register_shutdown_function(), предназначенной для регистрации специальной пользовательской функции, не связанной с работой скрипта. И, следовательно, способной выполнить дальнейшие преобразования, несмотря на то, что сам скрипт остановлен.
И таким образом, в случае возникновения фатальной ошибки управление передается этой зарегистрированной функции, являющейся в данном случае обработчиком.
Как может выглядеть регистрация пользовательской функции и перехват в ней последней ошибки, остановившей работу скрипта, показано в следующем фрагменте PHP-кода.
-
//—-Перехват и обработка фатальных ошибок PHP—-
-
function fatal_php(){ //Пользовательская функция
-
$error = error_get_last(); //Получение информации о последней произошедшей ошибке
-
if ($error !== NULL && in_array($error[‘type’], array(E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR))){ //Если ошибка произошла и ее тип соответствует фатальной ошибке
-
$domen = ‘http://’.$_SERVER[‘SERVER_NAME’]; //Домен сайта
-
header(«Location: $domen/page_500.php»); //Редирект на страницу 500
-
exit; //Прекращение выполнения текущего скрипта
-
}
-
}
-
register_shutdown_function(‘fatal_php’); //Регистрация пользовательской функции обработчика фатальных ошибок PHP
-
?>
Рис.4 Перехват и обработка фатальных ошибок PHP
Здесь все строки кода сопровождаются комментариями, поэтому подробно описывать каждую из них, нет смысла.
Можно лишь отметить, что регистрация пользовательской функции выполняется, как ранее было отмечено, с помощью register_shutdown_function(), расположенной в строке 11.
А сама функция обработчика с именем fatal_php() (поз.3÷10) в начале возвращает ассоциативный массив с описанием последней произошедшей ошибки (функция error_get_last() поз.4). А затем в случае, если выявленная ошибка относится к одному из четырех необходимых типов (E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR), то с помощью функции отправки HTTP-заголовка header() (поз.7) выполняется редирект по указанному аргументом «Location» адресу, соответствующему странице 500.
В случае, если фатальная ошибка PHP возникает в процессе формирования тела страницы при отправленном HTTP-заголовке, то при установках по умолчанию, в соответствии с протоколом HTTP должна возникнуть ошибка Cannot modify header information — headers already sent by (), означающая невозможность изменения заголовка после его отправки. Более подробно об этом и о том, как решить эту проблему мы посмотрим в следующем разделе статьи.
Таким образом при использовании созданной пользовательской функции, в случае, если из-за какой-то критической ошибки PHP-скрипт остановлен, обработчик ее обнаружит и выполнит необходимые действия по ее идентификации и дальнейшей обработке.
В данном случае обработка заключается всего лишь в выполнении редиректа на страницу 500. Но в дальнейшем, когда мы перейдем к сохранению логов и оправке сообщений по email, то здесь же будем использовать и другие, необходимые для этого преобразования.
И последнее, на что необходимо обратить внимание, функция обработчика должна быть расположена в самом начале кода шаблона главной страницы файла index.php. Иными словами, чтобы все остальные PHP-инструкции, используемые при формировании веб-страницы, выполнялись только после ее регистрации. В противном случае при остановке скрипта обработчик не будет вызван и, соответственно, не сможет выполнить свою задачу.
Буферизация вывода в PHP
В созданном обработчике фатальных ошибок PHP (рис.2) с помощью функции HTTP-заголовка header() (поз.7) предусматривается редирект на страницу 500.
Однако, здесь следует учесть одно обстоятельство, а именно: в случае редиректа, выполняемого в момент формирования тела веб-страницы, уже после отправки HTTP-заголовка, непременно должна последовать ошибка Cannot modify header information — headers already sent by ().
Обусловлено это следующим. По умолчанию сервер отправляет в браузер данные веб-страницы по мере их готовности, в процессе выполнения PHP-скрипта. При этом в соответствии с протоколом HTTP, сервер в ответ на запрос должен в первую очередь отправить служебные заголовки, а уж только потом код самого тела страницы. И протоколом HTTP не допускается ситуация, когда в момент передачи тела страницы производится повторная оправка HTTP-заголовка. О чем и говорит описание вышеуказанной ошибки.
В подтверждение этому можно проверить работу созданного обработчика по состоянию на данный момент, с заведомо внесенной критической ошибкой PHP.
На скриншоте показан вариант вывода страницы «Получить скидку», у которой в код PHP файла poluchit-skidku.php специально внесена синтаксическая ошибка.
Рис.5 Ошибка при изменении заголовка после его отправки
Как видно, здесь в области основного содержания, при обнаружении в ней фатальной ошибки Parse error и остановки скрипта, присутствует также и ошибка Cannot modify header information — headers already sent by (), означающая невозможность изменения заголовка в момент передачи кода данного блока веб-страницы.
А для того, чтобы решить эту проблему и иметь возможность изменять в любой момент HTTP-заголовки, применяется, так называемая буферизация вывода в PHP.
Суть ее в том, что в этом случае при выполнении PHP, сервер не оправляет страницу по мере ее готовности, а складывает полученный код в определенный буфер, параллельно формируя HTTP-заголовки, которые в обычном режиме не допускается оправлять в момент передачи тела страницы.
И только после того, как скрипт выполнит все заложенные в него операции, то всё, что в конечном итоге оказалось в буфере, разом отправляется в браузер пользователя в правильном порядке, как это определенно протоколом HTTP — сначала заголовки, а уж потом страница, сформированная скриптом.
В PHP существуют несколько функций, предназначенных для работы с буфером. Но для данной задачи мы будем использовать только две из них ob_start() — для включения буферизации вывода и ob_end_flush() — для отправки данных из буфера и отключения буферизации.
Схематично для генерируемой HTML-страницы это можно представить следующим образом.
kak-vyvesti-stranicu-oshibki-500_2
Рис.6 Буферизация вывода в PHP
А ниже показано, как в итоге будет выглядеть код шаблона главной страницы в файле index.php после дополнения его обработчиком фатальных ошибок PHP и элементами буферизации вывода PHP (светлым фоном обозначены дополнительные фрагмента кода).
kak-vyvesti-stranicu-oshibki-500_3
Рис.7 Файл index.php с обработчиком ошибок и буферизацией вывода
Следует отметить, что для оптимизации файла index.php, ранее размещенный в начале шаблона главной страницы PHP-код, предназначенный для получения данных при формировании динамической страницы, перенесен в файл start.php, который подключается соответствующей инструкцией в строке 13.
Таким образом буферизацию вывода HTML-страницы, генерированной скриптом PHP, мы выполнили. Однако, для полноценной работы сайта при обработке ошибки 500 необходимо сделать еще одно небольшое дополнение, которые мы сейчас и рассмотрим.
Дополнение файла .htaccess
Приведенные выше преобразования предназначены для выполнения редиректа на страницу 500 в случае прерывания работы скрипта при фатальных ошибках PHP.
Но для того, чтобы это происходило и в других случаях внутренней ошибки сервера, необходимо в файл .htaccess добавить директиву ErrorDocument, аналогичную той, которую мы использовали ранее при редиректе на страницу 404. Только теперь в ней должен быть указан соответствующий адрес /page_500.php.
А заодно, в целях безопасности полезно будет вообще отключить отображение системных сообщений на экране пользователя. Так как теперь возникающие по каким-либо причинам ошибки будут фиксироваться собственным механизмом обработки ошибок и нет необходимости их выводить в браузер. Тем более, что в определенных случаях такая излишняя для пользователя информация может быть использована недоброжелателями в качестве уязвимости сайта.
В итоге файл .htaccess следует дополнить следующими директивами, которые обеспечат выполнение вышеперечисленных действий.
-
ErrorDocument 500 /page_500.php
-
php_flag display_errors 0
Рис.8 Редирект 500 в файле .htaccess
Таким образом мы сделали все необходимые преобразования для вывода страницы 500. И теперь можно проверить, как это в реальности будет работать.
Проверка работы сайта при внутренней ошибке сервера
Проверку обработки внутренней ошибки сервера выполним на примере возникновения фатальной ошибки PHP, что позволит удостовериться в корректной работе, как созданного обработчики фатальных ошибок, так и процесса буферизации вывода генерируемой страницы и редиректа на страницу 500.
Для этого в код PHP временно внесем ту же самую синтаксическую ошибку, которую ранее мы делали на промежуточном этапе (рис.5). И посмотрим, как теперь будет обработана такая ситуация.
Рис.9 Вывод страницы 500 при фатальной ошибке PHP
Как видно, теперь критическая ошибка отработана должным образом, с перенаправлением на страницу ошибки 500.
При желании, можно проверить работу сайта и при других искусственно созданных фатальных ошибках. И во всех случаях результат должен быть один — отображение собственной страницы 500. Что в итоге и требовалось получить.
В следующей статье мы создадим механизм обработки не фатальных ошибок PHP, где с помощью собственного обработчика будет обеспечиваться их перехват и сохранение сообщений в соответствующем журнале.
.
Исходные файлы сайта
Исходные файлы сайта с обновлениями, которые были сделаны в данной статье, можно скачать из прилагаемых дополнительных материалов:
- Файлы каталога www
- Таблицы базы данных MySQL
Дополнительные материалы бесплатно предоставляются только зарегистрированным пользователям.
Для скачивания исходных файлов необходимо авторизоваться под своим аккаунтом через соответствующую форму.
Для тех кто не зарегистрирован, можно это сделать на вкладке Регистрация.
С уважением,
- Следующая сатья: Перехват и обработка не фатальных ошибок PHP
Если у Вас возникли вопросы, или есть какие-либо пожелания по представлению материала, либо заметили какие-нибудь ошибки, а быть может просто хотите выразить свое мнение, пожалуйста, оставьте свои комментарии. Такая обратная связь очень важна для возможности учета мнения посетителей.
Буду Вам за это очень признателен!
Я хочу симулировать эту ошибку, поэтому я могу проверить, что отображается общая страница ошибки, а не HTTP 500, в свете недавней уязвимости безопасности.
Мы включаем специальную обработку в самом сайте для 404 и 403, поэтому я хочу убедиться, что ошибки без специальной обработки тоже работают.
Ответ 1
throw new Exception();
Это создаст HTTP 500
Ответ 2
Я думаю, вы можете сделать это, переопределив инициализацию страницы и добавив код состояния 500 в ответ следующим образом:
protected void Page_Init(object sender, EventArgs e)
{
Response.Clear();
Response.StatusCode = 500;
Response.End();
}
Наслаждайтесь!
Ответ 3
вы можете разбить файл web.config. Поместите неверный тег для тестов
Ответ 4
Здесь можно сделать это без изменения вашего сайта:
- В своем веб-браузере откройте страницу на своем сайте с обратной формой.
- Нажмите F12, чтобы открыть инструменты разработчика.
- На вкладке HTML найдите __VIEWSTATE и каким-либо образом измените значение.
- Отправить в форму
Это приведет к ошибке «Проверка MAC-адреса в представлении» с ошибкой «ASP.Net Exception», которая возвращает код ответа HTTP с внутренней внутренней ошибкой сервера.
Разрыв web.config с неверным тегом также работает, но он побеждает цель, если вы пытаетесь проверить некоторые параметры в вашем web.config(например, Failed Request Tracing).
Ответ 5
Это генерирует пользовательский код ошибки HTTP в классическом asp.
<%@language=Jscript%>
<%
Response.Status = "996 TerraNova GeoWeb Internal Server Error";
Response.End;
%>