Кратко

  • Уже в HTTP/1.0 код 204 означал, что запрос выполнен, но новой информации для показа нет. Пользовательский агент должен был сохранить вид документа, из которого возник запрос.
  • No Content — не отсутствие состояния и не отсутствие метаданных. В современной семантике заголовки относятся к целевому ресурсу и выбранному представлению после действия; ETag в ответе на PUT может обозначить только что сохранённую версию.
  • Ответ 204 заканчивается вместе с секцией заголовков. В нём не может быть ни контента, ни trailers, а текущая спецификация запрещает и Content-Length. Пустота здесь задаёт границу протокола, а не представляет файл нулевой длины.

У сохранения оказалось два результата

Когда пользователь нажимает «Сохранить», серверу нужно изменить ресурс. Но из этого не следует, что браузеру нужно заменить рабочий документ. В ранних веб-сценариях эти события часто совпадали: действие завершалось переходом на новую страницу. Для редактора такой переход лишь мешает.

Редактору достаточно знать, что запись состоялась, получить при необходимости новую метку версии и продолжить работу с тем же курсором и контекстом. Отправлять обратно весь документ только ради подтверждения — значит путать состояние ресурса с представлением на экране.

204 разъединил эти решения. Сервер отвечает за свершившийся переход состояния. Пользовательский агент сохраняет поверхность, на которой началось действие. Ни одна сторона не получает лишней власти над другой.

Поэтому короткий ответ — не обеднённый ответ. Он точнее длинного там, где все необходимые факты уже умещаются в статусе и заголовках.

HTTP/1.0 закрепил непрерывность интерфейса

Опубликованный в мае 1996 года RFC 1945 определял 204 как выполненный запрос без новой информации, которую следовало бы вернуть. Если клиентом был пользовательский агент, он не должен был менять вид документа, породивший запрос.

Основным случаем назывались сценарии и другие действия: введённые данные могли подействовать, не вытесняя активный документ. При этом entity-заголовки могли нести новую метаинформацию, применимую к документу, который оставался перед пользователем.

Здесь с самого начала соседствовали две мысли. Отсутствие тела не ослабляло утверждение об успехе. Сохранение экрана не обязывало клиента сохранять устаревшее знание о версии.

Тот же стандарт относил 204 к ответам без тела. Речь шла не о случайно пустом представлении, а о статусе, для которого тело не предусмотрено.

HTTP/1.1 провёл линию после заголовков

В 1997 году RFC 2068 сохранил модель неизменной страницы и уточнил границу: у 204 нет message-body, ответ завершается первой пустой строкой после полей заголовков.

RFC 2616 в 1999 году сформулировал роль метаданных ещё яснее. Сервер выполнил запрос, не обязан возвращать entity-body, но может прислать обновлённую метаинформацию о запрошенном варианте. Пользовательский агент сохраняет текущий вид и применяет эту информацию к нему.

Разделы о методах помещали 204 после фактического исполнения. Завершённый DELETE без описывающего результат представления мог вернуть 204. Успешно изменивший существующий ресурс PUT — тоже, если представление результата не отправлялось.

Пустое место в ответе не было очередью ожидания. Операция уже пересекла границу фиксации.

204 не равен пустому 200

У ответа 200 нулевой длины и у 204 может быть одинаковое число октетов контента — ноль. Семантика от этого не совпадает.

200 обычно предъявляет контент успешного результата, даже если его длина оказалась нулевой. 204 утверждает, что для этого успешного результата дополнительный ответный контент не нужен. Код объясняет отсутствие и задаёт общие предположения о кадрировании и поведении интерфейса.

Клиенту не приходится гадать, потерялось ли ожидаемое представление. Сервер, со своей стороны, не может объявить 204, а затем незаметно дописать небольшой документ о состоянии.

Ноль байт способен быть данными. 204 — это законченное управляющее сообщение.

Заголовки смотрят в мир после действия

В 2014 году RFC 7231 уточнил временную привязку. Метаданные ответа 204 относятся к целевому ресурсу и его выбранному представлению после применения запрошенного действия.

Пример с PUT показывает практический смысл. Если успешный PUT получает 204 с ETag, этот ETag идентифицирует новое представление целевого ресурса. Редактор может обновить локальную метку версии, не скачивая заново документ, который только что сохранил.

Тело отсутствует, но идентичность результата остаётся. Date, Cache-Control и другие применимые поля продолжают сообщать факты. Клиент, выбрасывающий заголовки на том основании, что «204 — это ничего», теряет доказательство для следующего условного сохранения.

Нельзя и автоматически считать ETag отпечатком тела запроса. Метка относится к выбранному состоянию после обработки на origin-сервере, а тот мог преобразовать присланное представление.

Экран оставался прежним, знание двигалось вперёд

Не менять вид документа — не значит изображать отсутствие события. Предполагается, что пользовательский агент покажет успех средствами собственного интерфейса и применит обновлённые метаданные к активному представлению.

Origin решает, завершилось ли действие и какие сведения авторитетно описывают состояние после него. Пользовательский агент решает, как показать подтверждение, сохранить ли фокус и локальный контекст, нужен ли приложению последующий GET.

Так общая часть протокола остаётся тонкой. Она закрепляет минимум, необходимый разным реализациям, но не присваивает серверу управление рабочим процессом пользователя.

Страница может не сдвинуться ни на пиксель, а локальная модель — перейти на новую версию.

205 выбирает противоположную ветвь интерфейса

HTTP 205 Reset Content тоже не несёт ответного контента, однако отдаёт другую команду рабочей поверхности. Пользовательский агент должен сбросить вид документа, из которого возник запрос, подготовив его к следующему вводу.

204 сброса не требует. После обычного сохранения документ остаётся доступным для дальнейшего редактирования. Если библиотека сведёт все успехи без тела к одному UI-сценарию, она может очистить форму, убрать фокус или потерять локальные данные вопреки ответу сервера.

Таким образом, «нет контента» — недостаточная классификация. Сходство передачи скрывает различие контроля.

Пара соседних кодов показывает, зачем протоколу нужны типы отсутствия, а не один общий пустой ответ.

202 находится по другую сторону момента завершения

HTTP 202 Accepted также может быть кратким. Но он говорит, что обработка принята и ещё не завершена; более того, она может так и не завершиться.

204 заявляет об успешном исполнении. Повторить запрос только потому, что не пришло тело, — значит рисковать повторной оплатой, публикацией, конфигурационной операцией или удалением. Вернуть 204 до окончания асинхронной работы — значит, напротив, солгать о моменте commit и не дать клиенту корректного пути наблюдения.

Отличие особенно важно для действий, повторение которых имеет последствия. Длина ответа не доказывает завершение. Это делает статус.

Внешне пустые сообщения могут стоять до и после решающей границы. 202 и 204 называют сторону.

Секция заголовков и есть весь ответ

Современный RFC 9110 говорит, что 204 заканчивается с окончанием секции заголовков и не может содержать content или trailers. Сервер также не должен отправлять Content-Length.

Строгость защищает постоянное соединение. Неожиданные байты после ответа, чья семантика запрещает содержимое, разные получатели могут истолковать по-разному или принять за начало следующего сообщения. Автоматически добавленные JSON, перевод строки или трассировочный trailer превращают мелочь в конфликт парсеров.

Промежуточное ПО обязано учитывать статус. Даже привычный Content-Length: 0 здесь не является безобидным пояснением: текущая семантика запрещает само поле.

Пустая строка после заголовков не открывает пустой документ. Она закрывает ответ целиком.

Эвристическая кэшируемость не отменяет правила метода

RFC 7231 называл 204 кэшируемым по умолчанию. RFC 9110 употребляет более точную формулу heuristically cacheable, если определение метода или явные директивы не задают иное.

Это не универсальное разрешение хранить и повторно использовать всякий ответ POST, PUT или DELETE. RFC 9111 по-прежнему связывает хранение с методом, ключом кэша, свежестью и управляющими директивами.

Ценность в 204 могут иметь метаданные после операции, а не отсутствующее тело. Повторно применённый не в том контексте ETag способен приписать одной операции версию, созданную другой.

Origin должен осмысленно задавать Cache-Control для изменяющих состояние ответов. Кэш обязан учитывать метод. Экономия байтов не даёт права экономить контекст.

Иногда отсутствие контента скрывает недостаток контракта

204 уместен только тогда, когда клиент может правильно продолжить без представления результата. Некоторые бизнес-операции создают необходимый идентификатор, квитанцию, токен восстановления, описание конфликта или URI следующего шага.

Спрятать такие сведения за 204 — не минимализм, а неполный контракт приложения. HTTP разрешает не отправлять контент, но не объявляет любое умолчание разумным.

Если редактору нужна нормализованная сервером версия, он может получить её следующим запросом. 204 не запрещает последующий GET; он лишь не навязывает замену активного вида этим ответом.

Минимальная передача оправдана, когда исключённые байты действительно дублируют известное, а не несут единственное доказательство результата.

IANA хранит запись о точно очерченном отсутствии

Реестр кодов состояния HTTP IANA связывает 204 No Content с разделом 15.3.5 RFC 9110.

Короткое имя сворачивает несколько утверждений: действие успешно; дополнительного контента нет намеренно; заголовки описывают ресурс после действия; текущий вид не требуется заменять; сообщение заканчивается после заголовков.

204 не говорит, что сам ресурс пуст, отсутствует или удалён. Он не обесценивает заголовки и не отдаёт команду сбросить интерфейс.

У этого отсутствия есть причина, момент и граница, которую можно проверить на проводе.

Сохранение завершилось, не забрав экран

204 — проявление сдержанности протокола. Сервер знает, что действие выполнено, но не превращает это знание в право выбрать следующий экран пользователя. Общей истиной остаётся commit; локальная индикация и продолжение остаются у клиента.

Именно так работает тонкая обязательная прослойка: она фиксирует завершение, идентичность и фрейминг, а решения, которым нужен локальный контекст, оставляет конечной стороне.

Сдержанность не означает расплывчатость. Действие должно завершиться до ответа, метаданные обязаны быть правдивы, а после заголовков не должно быть ни одного лишнего байта.

Страница осталась на месте потому, что показывать больше нечего, а не потому, что ничего не произошло.