Коды состояния редиректа 3xx

Как работает редирект

Редирект - это два запроса, а не один. Клиент запрашивает URL A, сервер отвечает статусом 3xx и заголовком Location, называющим URL B, и клиент затем делает новый запрос к B. Браузеры следуют этому автоматически, поэтому посетитель видит только финальную страницу и финальный URL в адресной строке. Промежуточный ответ все равно стоит полного кругового пути, поэтому длинные цепочки редиректов работают медленно.

Коды 3xx отличаются друг от друга по двум свойствам. Первое - постоянство: постоянный редирект говорит клиентам и краулерам, что старый URL снят с эксплуатации, а новый должен заменить его в закладках, ссылках и индексах, тогда как временный редирект говорит, что старый URL по-прежнему настоящий и еще вернется. Второе - сохранение метода. Более старые коды позволяют клиенту превращать POST в GET при следовании редиректу, а более новые это запрещают, так что POST остается POST. Именно в этом разница между отправкой формы, доходящей до нового URL нетронутой, и той, что приходит как пустой GET.

Каждый код 3xx и что он означает

• 300 Multiple Choices. Ресурс существует в нескольких представлениях, и сервер предоставляет выбор клиенту. Стандартного машиночитаемого формата для такого списка не существует, поэтому почти никто это не реализует. На практике 300 вам не встретится. О том, почему он выживает в основном как поисковый запрос, смотрите руководство по 300 Multiple Choices.
• 301 Moved Permanently. У ресурса новый постоянный дом. Поисковые системы переносят сигналы ранжирования на цель, и клиентам разрешено кэшировать редирект, иногда агрессивно. Это код для смены домена, переезда с HTTP на HTTPS или постоянной перестройки URL.
• 302 Found. Временный редирект. Исходный URL сохраняет свою идентичность, поэтому поисковые системы обычно продолжают индексировать оригинал, а не цель. Исторически многие клиенты меняли метод на GET при следовании за 302, поэтому стандарт предостерегает от того, чтобы полагаться здесь на сохранение метода.
• 303 See Other. "Ваш запрос обработан; теперь сделайте GET на этот другой ресурс." Клиенту прямо говорят использовать GET для последующего запроса независимо от исходного метода. Это правильный ответ на POST формы, который должен привести на страницу результата.
• 304 Not Modified. Вообще не редирект. Он отвечает на условный запрос и означает "ваша закэшированная копия по-прежнему актуальна, используйте ее". Нет ни тела, ни Location. См. 304 Not Modified.
• 305 Use Proxy и 306 устарели. 305 отменен по соображениям безопасности, а 306 не используется. Игнорируйте оба.
• 307 Temporary Redirect. То же значение, что и 302, но метод и тело должны сохраняться. POST, следующий за 307, доходит до нового URL как POST.
• 308 Permanent Redirect. То же значение, что и 301, но метод и тело должны сохраняться.

Что идет не так с редиректами

• Временный код на постоянном переезде. Самая частая и самая дорогая ошибка. Поисковые системы продолжают держать старый URL в индексе, а новый не наследует репутацию старого.
• Постоянный код на временном переезде. Труднее отменить, потому что закэшированный 301 может еще долго после удаления правила продолжать отправлять вернувшихся посетителей не туда.
• Цепочки редиректов. http в https, затем non-www в www, затем старый путь в новый - это три круговых пути еще до того, как придет хоть какое-то содержимое. Каждый переход добавляет задержку, и на каждом переходе цепочка может сломаться.
• Циклы редиректов. A отправляет на B, а B отправляет обратно на A, обычно потому что правило на уровне приложения и правило на уровне сервера или CDN расходятся во мнении о канонической форме. Браузеры сдаются после фиксированного числа переходов и показывают ошибку.
• Все ведет на главную страницу. Когда снятые с публикации страницы все до одной редиректят на корень вместо ближайшего эквивалента, редирект часто трактуется как мягкий 404, и посетитель остается искать сам.
• Потерянные тела POST. Эндпоинт API или формы, перенесенный за 301 или 302, у некоторых клиентов может потерять метод и полезную нагрузку. Используйте 307 или 308 для всего, что не является простым GET.

Как проверить и исправить свои редиректы

1. Посмотрите, что возвращает URL, не следуя за ним:

   curl -sI https://example.com/old-page | grep -Ei "^(HTTP|location)"

   Это выводит строку статуса и цель за один раз.
2. Теперь пройдите всю цепочку и посчитайте переходы:

   curl -sIL -o /dev/null -w "%{num_redirects} hops, final %{http_code}, %{url_effective}\n" https://example.com/old-page

3. Сворачивайте цепочки до одного перехода. Направляйте исходный URL прямо на конечное назначение, а не позволяйте ему проходить через промежуточные правила.
4. Подбирайте код под намерение. Постоянный переезд: 301, либо 308, если эндпоинт принимает не-GET запросы. Временный переезд, страница обслуживания или A/B-разделение: 302, либо 307, если метод должен сохраниться. Поток post-затем-редирект: 303.
5. Исправляйте циклы, определив каноническую форму (протокол, хост и завершающий слеш) один раз и применяя ее ровно на одном слое. Циклы почти всегда означают, что два слоя пытаются быть авторитетными одновременно.
6. Перепроверяйте на холодном кэше. Браузер, уже закэшировавший 301, продолжит ему подчиняться, поэтому подтвердите через curl или приватное окно, прежде чем сделать вывод, что исправление не сработало.

Как поймать сломанный редирект до падения трафика

Редиректы ломаются без каких-либо видимых симптомов. Правило, начавшее зацикливаться, или сертификат, отказывающий на цели редиректа, все еще оставляют старый URL отвечающим, поэтому ничего не выглядит подозрительно, пока не падают трафик и позиции. Внешняя проверка, которая проходит цепочку и проверяет финальный статус, ловит сломанный редирект в момент появления, а проверка из многих сетей отличает глобальное изменение правила от регионального сбоя CDN. HostTracker выполняет проверки из 300+ точек в 158 городах и оповещает по email, SMS, голосовым звонком, в Slack, Telegram и другими способами. Проверьте URL и его цепочку редиректов с помощью инструмента HTTP-проверки, а перед выбором кода почитайте 301 против 302.