RFC 7231

RFC 7231 — это документ, опубликованный в 2014 году в рамках серии запросов комментариев (RFC) Инженерного совета Интернета (IETF), который определяет семантику и содержание протокола передачи гипертекста (HTTP/1.1). Он является частью более широкой спецификации HTTP/1.1, заменившей предыдущий стандарт RFC 2616, и описывает, как веб-серверы и клиенты (например, браузеры) должны интерпретировать и обрабатывать HTTP-запросы и ответы, включая методы, коды состояния, заголовки и правила кэширования.

История

Протокол HTTP/1.1 был первоначально определён в RFC 2068 (1997 год), а затем пересмотрен в RFC 2616 (1999 год). К началу 2010-х годов накопилось множество уточнений и исправлений, выявленных в ходе практического использования. В 2007 году IETF сформировала рабочую группу HTTPbis (Hypertext Transfer Protocol bis), которая занялась переработкой RFC 2616. Целью было не создание нового протокола, а разделение объёмного документа на несколько более узких и чётких спецификаций, устранение двусмысленностей и приведение стандарта в соответствие с реальной практикой.

RFC 7231 был опубликован в июне 2014 года как часть набора из шести документов, заменивших RFC 2616:

• RFC 7230 — Message Syntax and Routing (синтаксис сообщений и маршрутизация).
• RFC 7231 — Semantics and Content (семантика и содержимое).
• RFC 7232 — Conditional Requests (условные запросы).
• RFC 7233 — Range Requests (запросы диапазонов).
• RFC 7234 — Caching (кэширование).
• RFC 7235 — Authentication (аутентификация).

Впоследствии, в 2022 году, HTTP/1.1 был пересмотрен и опубликован как RFC 9110 (Semantics) и RFC 9112 (HTTP/1.1), которые заменили RFC 7231 и RFC 7230 соответственно. Несмотря на это, RFC 7231 остаётся важной вехой в стандартизации HTTP и широко цитируется в документации и учебных материалах.

Основные положения

RFC 7231 определяет фундаментальные аспекты взаимодействия по протоколу HTTP/1.1. Он описывает, как клиент и сервер обмениваются сообщениями, какие действия могут быть запрошены и как сервер должен на них отвечать.

Методы HTTP

Одним из ключевых разделов RFC 7231 является определение методов HTTP (или глаголов), которые указывают на желаемое действие с ресурсом. Документ устанавливает следующие стандартные методы:

• GET — запрос представления указанного ресурса. Должен быть безопасным (не изменяет состояние сервера) и идемпотентным (повторный запрос даёт тот же результат).
• HEAD — запрос, аналогичный GET, но сервер не должен возвращать тело ответа. Используется для получения метаданных (например, заголовков) без передачи содержимого.
• POST — запрос на обработку данных, включённых в тело запроса. Часто используется для создания новых ресурсов или отправки данных на сервер. Не является идемпотентным.
• PUT — запрос на замену указанного ресурса данными из тела запроса. Идемпотентен.
• DELETE — запрос на удаление указанного ресурса. Идемпотентен.
• CONNECT — запрос на установление туннеля к серверу (например, для HTTPS через прокси).
• OPTIONS — запрос на получение информации о доступных методах и других возможностях сервера для указанного ресурса.
• TRACE — запрос на отражение полученного запроса обратно клиенту (используется для диагностики).

RFC 7231 также разрешает расширение набора методов, но требует, чтобы неизвестные методы обрабатывались как небезопасные и неидемпотентные.

Коды состояния

Документ определяет коды состояния HTTP, которые сервер возвращает в ответ на запрос. Они сгруппированы по классам:

• 1xx (Informational) — информационные (например, 100 Continue, 101 Switching Protocols).
• 2xx (Successful) — успешные (например, 200 OK, 201 Created, 204 No Content).
• 3xx (Redirection) — перенаправления (например, 301 Moved Permanently, 302 Found, 304 Not Modified).
• 4xx (Client Error) — ошибки клиента (например, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found).
• 5xx (Server Error) — ошибки сервера (например, 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable).

RFC 7231 уточняет семантику многих кодов, в частности, различие между 301 (постоянное перенаправление) и 302 (временное), а также вводит код 308 (Permanent Redirect) для сохранения метода запроса при перенаправлении.

Заголовки

RFC 7231 определяет множество заголовков HTTP, которые управляют кэшированием, аутентификацией, согласованием содержимого и другими аспектами. Ключевые заголовки включают:

• Content-Type — тип содержимого тела ответа (например, text/html, application/json).
• Content-Length — размер тела ответа в байтах.
• Content-Encoding — кодировка, применённая к телу (например, gzip).
• Host — обязательный заголовок запроса, указывающий доменное имя сервера.
• User-Agent — идентификация клиентского приложения.
• Referer — адрес страницы, с которой был сделан запрос.
• Location — URL для перенаправления.
• Allow — список методов, разрешённых для ресурса.
• Vary — указывает, какие заголовки запроса влияют на выбор представления ресурса.

Согласование содержимого

RFC 7231 описывает механизмы согласования содержимого (content negotiation), которые позволяют серверу выбирать наиболее подходящее представление ресурса (например, язык, формат, кодировку) на основе заголовков запроса (Accept, Accept-Language, Accept-Encoding). Документ различает серверно-управляемое согласование (когда сервер сам выбирает вариант) и агентно-управляемое (когда клиент получает список вариантов и выбирает сам).

Кэширование

Хотя основная спецификация кэширования вынесена в RFC 7234, RFC 7231 определяет базовые правила для кэшируемости ответов. В частности, он устанавливает, что ответы на методы GET и HEAD обычно могут кэшироваться, а ответы на POST — только при наличии явных указаний. Также он определяет, как заголовки Cache-Control, Expires и Last-Modified влияют на кэширование.

Применение

RFC 7231 является основой для разработки веб-серверов, клиентов (браузеров, мобильных приложений), прокси-серверов и любых других программ, взаимодействующих по протоколу HTTP/1.1. Он широко используется в:

• Веб-разработке — при создании RESTful API, где методы HTTP (GET, POST, PUT, DELETE) соответствуют операциям CRUD (Create, Read, Update, Delete).
• Администрировании серверов — для настройки кэширования, перенаправлений и обработки ошибок.
• Тестировании — для проверки корректности реализации HTTP-клиентов и серверов.
• Безопасности — для анализа кодов состояния и заголовков, связанных с аутентификацией и авторизацией.

Критика и ограничения

Несмотря на широкое распространение, RFC 7231 подвергался критике за некоторые недостатки:

• Сложность — документ объёмный и детализированный, что затрудняет его полное понимание и реализацию.
• Неоднозначности — некоторые формулировки, особенно в отношении кэширования и условных запросов, оставались предметом споров.
• Устаревание — с развитием HTTP/2 и HTTP/3, а также с появлением новых требований (например, к безопасности), RFC 7231 был заменён более современными стандартами (RFC 9110 и RFC 9112).

Тем не менее, RFC 7231 остаётся важным историческим документом и практическим руководством для понимания семантики HTTP/1.1.

Интересные факты

• RFC 7231 является одним из наиболее цитируемых документов IETF в области веб-технологий.
• В документе впервые официально закреплён метод PATCH (хотя он был определён в отдельном RFC 5789), который используется для частичного обновления ресурсов.
• RFC 7231 явно указывает, что серверы не обязаны поддерживать все методы, но должны корректно обрабатывать неизвестные методы, возвращая код 501 (Not Implemented) или 405 (Method Not Allowed).

Источники

• RFC 7231 — Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, IETF, 2014.
• RFC 2616 — Hypertext Transfer Protocol — HTTP/1.1, IETF, 1999.
• RFC 9110 — HTTP Semantics, IETF, 2022.
• Fielding, R. T., & Reschke, J. F. (Eds.). (2014). HTTP/1.1: Semantics and Content. RFC 7231.
• Gourley, D., & Totty, B. (2002). HTTP: The Definitive Guide. O'Reilly Media.