Nginx не только отлично справляется со статическими файлами и обеспечивает их высокую производительность при использовании обратного прокси-сервера для другого сервиса, но и обладает мощным механизмом обработки запросов, что позволяет нам управлять внешними запросами, поступающими через HTTP, а также генерировать внутренние запросы генерируются тем же Nginx в соответствии с условиями, которые мы программируем.
Внешние и внутренние петиции
Первый шаг, который мы должны сделать, - это распознать внешние и внутренние запросы, их имена уже достаточно хорошо это отражают, внешние запросы принимаются Nginx вне их системы через HTTP, а затем, когда пользователь вводит URL-адрес, который напрямую противоречит Наш сервис - это внешний запрос.
Внутренний запрос
Внутренний запрос вместо этого генерируется в том же Nginx, это может быть связано с внешним запросом или нет, хотя он является относительным, поскольку все события обычно инициируются пользовательскими запросами.
Итак, если, например, мы попадаем на 404- страничный ответ, не найденный, Nginx, если у него настроены какие-либо правила, может инициировать внутренний запрос, который заставляет пользователя увидеть персонализированное сообщение.
Типы внутренних петиций
Существует два типа внутренних запросов, которые может генерировать Nginx :
Внутренние перенаправления
В этом типе перенаправления Nginx направляет запросы клиента внутренне, таким образом, URL изменяется, и затем запрос может меняться между блоками расположения, которые мы определили на нашем сервере, один из наиболее распространенных случаев такого типа запросов - это когда мы активируем модуль Rewrite .
Подзапросы
Это когда генерируются дополнительные запросы, которые могут дополнять контент, например, когда мы используем модуль add_after_body, который позволяет нам добавлять контент в результат запроса.
Error_page block
Блок error_page также является одним из функциональных примеров того, как мы можем устанавливать внутренние запросы, давайте посмотрим на этот простой пример:
На рисунке мы видим, как мы настроили наш сервер таким образом, чтобы при получении запроса, который генерирует ошибку, Nginx перенаправлял непосредственно к подготовленным нами документам, чтобы клиент не нашел необработанный ответ.
Теперь, если мы хотим переписать вышеизложенное и получить его во внутренней петиции, мы можем принять следующую форму более детально:
Здесь мы видим, как мы определили, что когда мы получаем код ошибки 404, мы отправляем его в определенное место, которое является папкой ошибок, но позже мы определяем, что, когда у нас есть запрос к папке ошибок, мы сделаем внутренний запрос таким образом, только Nginx может получить доступ к этому содержимому, поэтому, если кто-то попытается сделать это извне, у него не будет доступа к нему.
На этом мы завершим этот урок, с помощью которого мы увидим, что правильное использование внутренних запросов может помочь нам повысить безопасность нашего сайта, не давая им доступа к этим ресурсам извне.
СТАТЬИ