Повний посібник з кодів стану HTTP. Серія 300

Щоб краще зрозуміти, чому перенаправлення такі важливі, корисно спершу зрозуміти, навіщо перенаправлення взагалі потрібне.

Перенаправлення зазвичай є наслідком зміни. Це може бути зміна обчислювальних ресурсів, зміна маркетингової термінології, зміна політики, зміна SEO-стратегії або зміна бізнес-процесів. Десь щось змінилося, і той самий URI має бути доступним за іншою адресою.

Коли вносяться зміни, пошукові системи та інші ресурси зберігають старі посилання, доки сайт не буде переіндексовано.

Альтернативою перенаправленню була б помилка 404 «документ не знайдено».

Крайній сценарій, що змушує перенаправляти user-agent: компанія реорганізує лінійку продуктів. Скажімо, ACME Co. перенесла лінійку Widgets до ACME Labs. Чинна політика ACME визначає веб-структуру як: acmeco/{division}/{productline}.

Тож ACME може мати:

www.acme.com
www.acme.com/marketing/seotechnologies/
www.acme.com/marketing/billboards/
www.acme.com/consumergoods/sports/
www.acme.com/consumergoods/clothing/
www.acme.com/consumergoods/widgets/
www.acme.com/labs/widgets/
www.acme.com/labs/foobars/
www.acme.com/labs/betaproducts/

ACME Widgets останні 5 років розташовувалися за адресою www.acme.com/consumergoods/widgets/ і отримують десятки тисяч переходів на годину за цією адресою.

Уявіть, скільки доходу цей простий переїзд може коштувати ACME Co. у втрачених продажах, у роботі служби підтримки зі скаргами, а також у часі керівників, які відповідають на дзвінки з офіційними заявами для преси про улюблену лінійку Widget?

А пошукові системи? Чимала частка продажів Widget в ACME Co. приходить із пошукових переходів. Не кажучи вже про кампанію Google Ads та URL на брошурах і візитках.

Перенаправлення серії 300 вирішує проблему для всіх в ACME Co. ACME може просто налаштувати веб-сервер так, щоб він перенаправляв усі запити до www.acme.com/consumergoods/widgets/ на www.acme.com/labs/widgets/.

(hr)

Реальний приклад перенаправлення 301

У EuroVPS ми використовуємо перенаправлення 301, щоб відвідувачі гарантовано користувалися захищеним протоколом HTTPS.

Ось як саме перенаправлення 301 гарантує, що кожен відвідувач потрапить на HTTPS, заходячи на EuroVPS:

1. user-agent запитує http://www.eurovps.com/
2. веб-сервер відповідає кодом стану 301
3. веб-сервер встановлює заголовок Location на https-версію
4. більшість user-agent автоматично переходять на новий URL

Перенаправлення можна реалізувати у скриптових мовах, таких як Python Django, PHP і ASP .Net. Проте надійніше рішення: залишити перенаправлення веб-серверу з правилом переписування.

Перенаправлення в PHP:

  <?php // Permanent 301 Redirect via PHP
  	header("HTTP/1.1 301 Moved Permanently");
  	header("Location: https://eurovps.com/");
  	exit; // stop the script once the redirect is sent

Проблема перенаправлень на такому високому рівні в тому, що може довестися редагувати 100 сторінок! Або ще гірше: ламати код у системі керування вмістом, яка може робити перенаправлення не так, як нам потрібно.

Значно елегантніше рішення: доручити все перенаправлення веб-серверу.

В Apache перенаправлення можна зробити так:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

В nginx те саме перенаправлення є одним рядком у блоці server, який слухає порт 80:

server {
    listen 80;
    server_name www.example.com;
    return 301 https://$host$request_uri;
}

(hr)

Перенаправлення з кодами стану 300

300 Multiple Choices

300 Multiple Choices є перенаправленням, яке рідко використовується на практиці. 300 Multiple Choices виникає, коли запитаний ресурс вказує на кілька призначень для того самого документа. Кінцевому користувачеві пропонується вибір дії, і він обирає потрібний варіант.

301 Moved Permanently

Перенаправлення 301 поширені, бо пошукові системи трактують 301 як постійний переїзд: вони оновлюють індекс на новий URI і переносять сигнали ранжування.

Коли клієнт зустрічає 301, закладки та автоматизовані user-agent слід оновити на новий URI.

302 Found

Перенаправлення 302 слід використовувати, коли запитаний URI тимчасово перебуває за новою адресою. User-agent іде за заголовком Location до тимчасового URI. З історичних причин більшість клієнтів перетворюють POST на GET, коли йдуть за 302; використовуйте 307, коли метод має зберегтися.

На відміну від 301, user-agent мають і далі використовувати початковий URI, бо це тимчасове перенаправлення.

303 See Other

303 призначений головно для запитів POST і PUT, які спрямовуються на інший URI, ніж user-agent запитував у своєму POST чи PUT.

Прикладом може бути завантаження великого файлу, яке триває кілька хвилин:

1. user-agent надсилає великий файл через PUT або POST
2. файл призначений для початкового URI
3. веб-сервер повертає 303 з перенаправленням на сторінку стану завантаження
4. user-agent через 303 використає GET, запитуючи сторінку стану завантаження

304 Not Modified

304 Not Modified використовується для кешування. 304 надсилається як стан user-agent, який запитує перевірку актуальності кешованої сторінки.

Якщо запитана сторінка досі актуальна, сервер відповідає 304 без тіла, і user-agent показує кінцевому користувачеві свою кешовану копію.

305 Use Proxy (застарілий)

305 Use Proxy є застарілим. Чинна специфікація HTTP, RFC 9110, позначає його як такий, що більше не використовується, і браузери на нього не реагують. Не використовуйте його.

307 Temporary Redirect

307 схожий на 302, але вимагає використання того самого методу запиту на перенаправленому URI. Це використовується, наприклад, коли запит POST потрібно надіслати на інший URI.

Із 302 більшість клієнтів переходять на запит GET, щоб отримати перенаправлений URI.

308 Permanent Redirect

308 є постійним відповідником 307. Як і 301, він каже клієнтам, що ресурс переїхав назавжди; як і 307, він вимагає від клієнта повторити запит тим самим методом. Використовуйте його, коли постійний переїзд має зберегти POST як POST.

Коди стану в цьому посібнику визначені в RFC 9110 (HTTP Semantics).