300 Multiple Choices: код, який ви майже ніколи не побачите

Для чого код був задуманий

HTTP підтримує узгодження вмісту: та сама URL може мати кілька представлень, що різняться форматом, мовою чи кодуванням. Зазвичай вирішує сервер, використовуючи заголовки клієнта Accept, Accept-Language і Accept-Encoding, і повертає обране з кодом 200. Це узгодження, кероване сервером, і саме так працює вебмережа.

300 Multiple Choices охоплює інший підхід, узгодження, кероване агентом. Замість того, щоб обирати самому, сервер відповідає списком доступних представлень і дає клієнту чи користувачу обрати. Відповідь може містити заголовок Location, що називає бажаний варіант сервера, за яким клієнт може, але не зобов'язаний, піти.

Чому ви майже ніколи його не бачите

Стандарт ніколи не визначав машинозчитуваний формат для списку варіантів. Без узгодженого формату браузеру нема що розбирати, тож жоден масовий браузер не реалізує інтерфейс вибору для 300. Браузери зазвичай показують тіло відповіді як звичайну сторінку, або йдуть за заголовком Location, якщо він є, що змушує 300 поводитися як слабкий редирект. Фреймворки застосунків і CDN не видають його в типових конфігураціях, а узгодження, кероване сервером, вирішує ту саму проблему непомітно і краще, тож ні в кого немає причин переходити на 300.

300 все ж з'являється в кількох місцях:

• У mod_negotiation Apache з увімкненим MultiViews, коли кілька файлів відповідають запиту на кшталт /logo, а модуль не може їх упорядкувати. Він генерує HTML-список кандидатів.
• У написаних вручну API, що навмисно повертають JSON-список альтернативних URL ресурсу, використовуючи 300 як семантичну підказку, а не очікуючи, що якийсь клієнт оброблятиме це нативно.
• У тестових наборах і інструментах перевірки відповідності протоколу, що прогонюють кожен визначений код статусу.

Чому люди шукають код статусу 300

Більшість пошуків "300 status code" узагалі не про 300. Це число - початок родини редиректів, тож люди, що побачили редирект в інструменті браузера, лозі чи SEO-краулері й запам'ятали "щось три-сто", шукають спершу саме 300. Насправді в них зазвичай є:

• 301, постійний редирект, про який повідомляє SEO-краулер як частину ланцюжка.
• 302, тимчасовий редирект, типовий для багатьох фреймворків.
• 304, що є відповіддю валідації кешу, а не редиректом узагалі.
• Зведення краулера, що групує все під заголовком "3xx", яке потім читають як "300".

Якщо ви намагаєтеся з'ясувати, який саме редирект повертає URL, посібник 301 проти 302 - саме те, що вам потрібно.

Як перевірити, чи у вас справді 300

1. Запитайте заголовки, не йдучи за жодним редиректом, і прочитайте точне число:

   curl -sI https://example.com/some-path | grep -Ei "^(HTTP|location|link|alternates)"

   Справжній 300 показує HTTP/1.1 300 Multiple Choices. Усе інше - це інший код і інший посібник.
2. Якщо це справді 300 і ви цього не планували, спершу подивіться на Apache. Вимкнення MultiViews для цієї директорії, чи явне вказання розширення файлу в URL, прибирає неоднозначність, що запускає узгодження.
3. Якщо ви хочете, щоб вибирав сервер, лишайтеся на узгодженні, керованому сервером: повертайте 200 з обраним представленням і заголовком Vary, що називає заголовки запиту, за якими ви узгоджували, тож кеші зберігатимуть варіанти окремо.
4. Якщо ви хочете надсилати клієнтів деінде, використовуйте справжній редирект. Постійні переміщення отримують 301 чи 308, тимчасові - 302 чи 307. Не використовуйте 300 як редирект, бо клієнти не зобов'язані за ним іти.
5. Виправте неоднозначність у джерелі. 300 майже завжди означає, що два файли чи два маршрути конкурують за той самий URL, і надійне виправлення - зробити URL однозначним.

Виявити неочікуваний 300 після деплою

Неочікуваний 300 зазвичай приходить разом з оновленням сервера чи зміною конфігурації, і ніхто цього не помічає: сторінка все ще може виглядати більш-менш нормально в браузері, тоді як краулери й клієнти API отримують відповідь, якою не можуть скористатися. Зовнішня перевірка, що записує точний код статусу для кожного URL, виявляє зміну вже при першому запуску після деплою. HostTracker моніторить вебсайти з 2004 року і виконує перевірки з понад 300 контрольних точок у 158 містах. Перевірте, що URL повертає просто зараз, за допомогою інструмента HTTP-перевірки, або прочитайте повний посібник про родину редиректів 3xx.