300 Multiple Choices: код, который вы почти никогда не увидите

Для чего был задуман этот код

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

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

Почему вы почти никогда его не увидите

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

300 все же встречается в нескольких местах:

• mod_negotiation Apache с включенным MultiViews, когда нескольким файлам соответствует запрос вроде /logo, а модуль не может их ранжировать. Он генерирует HTML-список кандидатов.
• Написанные вручную API, намеренно возвращающие JSON-список альтернативных URL ресурсов, используя 300 как смысловую подсказку, а не ожидая, что какой-либо клиент обработает его нативно.
• Тестовые наборы и инструменты проверки соответствия протоколу, прогоняющие каждый определенный код состояния.

Почему люди ищут код состояния 300

Большинство поисковых запросов про "код состояния 300" вообще не про настоящий 300. Это число - начало семейства редиректов, поэтому люди, увидевшие редирект в инструменте браузера, логе или SEO-краулере и запомнившие "что-то на 3 сотни", сначала ищут именно 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.