HEAD и OPTIONS: что они сообщают и зачем нужны клиентам

Что это такое

По RFC 9110 HEAD идентичен GET, кроме того, что сервер НЕ ДОЛЖЕН отправлять содержимое. Серверу СЛЕДУЕТ отправлять те же поля заголовков, что и для GET, но он МОЖЕТ опустить поля, значения которых становятся известны только при формировании содержимого, например Content-Length или Vary для буферизованного динамического ответа. Тело запроса HEAD не имеет определённого смысла и может привести к закрытию соединения из-за подозрения на контрабанду HTTP-запросов. Ответы HEAD кешируются; согласно RFC 9111, кеш использует ответ HEAD для обновления сохранённого ответа GET, если валидаторы и Content-Length совпадают, а иначе считает сохранённый ответ устаревшим.

OPTIONS запрашивает сведения о возможностях обмена для ресурса либо для сервера в целом, если целью является *. RFC 9110 описывает последний вариант как проверочный запрос, который проверяет возможности, не подразумевая действия над ресурсом. Успешному ответу СЛЕДУЕТ включать заголовки с описанием дополнительных возможностей, прежде всего Allow; формат тела не определён; HTTP-кеши не могут кешировать такие ответы; Max-Forwards позволяет адресовать запрос конкретному прокси в цепочке. В CORS браузер отправляет предварительный OPTIONS-запрос с Access-Control-Request-Method и Access-Control-Request-Headers и ожидает соответствующие заголовки Access-Control-Allow-* в ответе. MDN отмечает, что для этого ответа допустимы и 200, и 204, но некоторые браузеры некорректно обрабатывали 204.

Почему это важно

Проверяющие ссылки программы, менеджеры загрузок, читающие Content-Length и Accept-Ranges, средства контроля доступности и поисковые роботы полагаются на HEAD. Фреймворк, отвечающий на HEAD кодом 405 или возвращающий заголовки, отличающиеся от GET, заставляет их сообщать неверные результаты. OPTIONS — это запрос браузера перед любым непростым межсайтовым запросом; API, отвечающий на него 404, 401 или перенаправлением, непригоден для использования из браузера независимо от заголовков CORS.

Как применять

• Автоматически формируйте HEAD для каждого маршрута GET; сохраняйте одинаковыми статус, Content-Type, ETag и Last-Modified и по возможности не создавайте тело.
• Применяйте к HEAD ту же авторизацию, что и к GET; не раскрывайте существование защищённого ресурса через отличающийся статус.
• В ответе OPTIONS передавайте Allow, рассчитанный по маршрутизатору; также включайте Allow в ответы 405, как требует RFC 9110.
• Обрабатывайте предварительные запросы до аутентификации: MDN указывает, что они никогда не должны содержать учётные данные. Задавайте Access-Control-Max-Age, чтобы браузер кешировал результат.
• Явно маршрутизируйте OPTIONS *; маршрутизаторы, основанные на путях, часто превращают его в 404.

Подводные камни

Ответ HEAD может содержать Transfer-Encoding: chunked и при этом не иметь тела. Промежуточный слой, вычисляющий Content-Length путём формирования тела, лишает HEAD его преимущества. Кеш предварительных запросов CORS и HTTP-кеш — разные механизмы; срок хранения результата предварительного запроса в браузере задаётся Access-Control-Max-Age, а не Cache-Control.