Клиентам, использующим обратный HTTP-прокси Qrator Labs, доступна возможность настроить некоторые виды HTTP-перенаправлений на стороне обратного HTTP-прокси. При использовании этой услуги запросы, требующие перенаправления, будут обрабатываться непосредственно обратным HTTP-прокси без обращения к апстриму.
Одно из популярных применений HTTP-перенаправлений — принудительное включение протокола HTTPS для всех пользовательских запросов (см. пример конфигурации в конце статьи). В этом случае обработку HTTP-запросов в сети клиента можно отключить полностью, поскольку до апстрима будут доходить только запросы, сделанные по HTTPS. Такая конфигурация снижает количество запросов, отправляемых на апстрим.
Важно
Если вы планируете включить для домена защиту от ботов (см. Перенаправление с установкой cookie), то важно, чтобы перенаправления с HTTP на HTTPS выполнял не сам апстрим, а обратный прокси Qrator Labs. В противном случае защита от ботов будет работать некорректно.
Принцип работы
В настройках домена в личном кабинете Qrator Labs находится раздел HTTP-перенаправления
со списком правил. Создавая и редактируя эти правила, вы можете управлять поведением обратного HTTP-прокси. Правила могут быть добавлены в любом порядке.
При поступлении входящего запроса обратный прокси ищет во всём списке правил наиболее специфичное правило, которое может быть применено к запросу. Это позволяет настраивать сложные комбинации правил перенаправления, см. Примеры.
У каждого правила есть условия, при которых оно должно срабатывать (Запрос
):
-
протокол, который использовал пользователь в исходном запросе — HTTP или HTTPS,
-
хост, к которому сделан запрос — конкретная строка либо значение
ANY
, соответствующее любому хосту.
Если обратный HTTP-прокси нашёл в списке правило, подходящее для текущего запроса, он выполняет описанные в нём действия (Перенаправление
).
-
Пользователю может быть отправлен код HTTP-ответа, выбранный вами из списка:
- 301 Moved Permanently
- 302 Found
- 307 Temporary Redirect
- 308 Permanent Redirect
-
При составлении URL, на который будет совершено перенаправление, будут использованы хост и путь, введённые вами либо скопированные из исходного запроса.
-
GET-аргументы могут быть скопированы из исходного запроса либо удалены.
-
Перенаправление для конкретного правила может быть выключено полностью. В этом случае запросы, соответствующие условиям этого правила, будут переданы в вашу сеть.
Примеры
Принудительное включение протокола HTTPS
| Запрос | Перенаправление |
|---|---|
http://ANY |
301 https://$hostname $path?$args |
В этой конфигурации обратный HTTP-прокси заменяет протокол у всех поступающих запросов с HTTP на HTTPS. Рекомендуется использовать код состояния 301 Moved Permanently, чтобы браузер пользователя мог кешировать ответ на своей стороне и не выполнять обращения по протоколу HTTP в следующий раз.
Создание исключений из правила
| Запрос | Перенаправление |
|---|---|
http://ANY |
301 https://$hostname $path?$args |
http://old.example.com |
Выключено |
Этот пример аналогичен примеру с принудительным перенаправлением на HTTPS, но к нему добавлено второе правило, которое говорит, что для запросов к хосту old.example.com перенаправление выполняться не должно. Обратный HTTP-прокси при сопоставлении запроса с правилами отдаёт предпочтение более точному совпадению, поэтому первое правило перестаёт срабатывать для запросов к old.example.com.
Такая конфигурация может быть полезна, если среди сайтов, обслуживаемых вашим апстримом, есть один или несколько, которые не поддерживают работу по защищённому протоколу HTTPS, но вы хотите принудительно включать этот протокол для всех остальных сайтов.
Перенаправление на новый хост
| Запрос | Перенаправление |
|---|---|
https://ANY |
301 https://www.example.com/ |
https://www.example.com |
Выключено |
Предположим, что содержимое вашего сайта находилось на хостах wiki.example.com, app.example.com и других поддоменах *.example.com, обслуживаемых одним апстримом, но после изменения структуры возникла необходимость перенаправлять всех посетителей с этих хостов на главную страницу сайта на новом основном хосте www.example.com.
В такой ситуации вы можете создать два правила, как описано выше. Под первое условие в первом правиле попадают все HTTPS-запросы, но второе правило создаёт исключение из первого для основного хоста, не допуская таким образом циклических перенаправлений.