Коди статусу перенаправлення 3xx

Як працює редирект

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

Дві властивості відрізняють коди 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, тоді старий шлях на новий - це три round trip, перш ніж прийде хоч якийсь контент. Кожен перехід додає затримку, і кожен перехід - місце, де ланцюжок може зламатися.
• Цикли редиректів. 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 містах і сповіщає електронною поштою, SMS, голосовим дзвінком, у Slack, Telegram та іншими способами. Перевірте URL-адресу і її ланцюжок редиректів за допомогою інструмента HTTP-перевірки, а перш ніж обирати код, читайте 301 проти 302.