Что делать, если при тестировании ожидается статус 200 OK с телом, а приходит 304 без тела

Что проверяют

Знаете ли вы, что 304 это штатный ответ на условный запрос, а не поломка, и умеете ли отличить дефект сервера от особенности своего инструмента. Это проверка на понимание кэширования по HTTP и на аккуратность баг-репорта.

Как отвечать

Объясните механику. Клиент, у которого уже есть копия ответа, шлёт условный запрос: If-None-Match с прежним ETag или If-Modified-Since с датой. Если ресурс не менялся, сервер отвечает 304 и не отдаёт тело, потому что тела в этом ответе быть и не должно. Само по себе это не баг.

Порядок проверки:

• посмотрите заголовки своего запроса. Если условные заголовки есть, сравнение попросили вы сами;
• повторите запрос без них: curl -i -H 'If-None-Match:' <адрес> или новый клиент без истории;
• проверьте, не стоит ли перед сервисом кэширующий прокси, который отвечает вместо приложения;
• измените ресурс и повторите условный запрос с прежним ETag.

Вот последний шаг и отделяет дефект: если данные изменились, а сервер по старому ETag продолжает отвечать 304, значит валидатор не пересчитывается. Частая причина: Last-Modified с точностью до секунды теряет правки внутри той же секунды, либо ETag считается по чему-то, что от содержимого не зависит.

В баг кладите оба обмена целиком: заголовки запроса и ответа, прежний и текущий ETag, шаги и доказательство, что тело реально другое.

Где спотыкаются

Пишут баг «приходит 304 вместо 200», не приложив заголовки запроса. Разработчик видит корректное по спецификации поведение и закрывает как не воспроизводится.

Второе: ждут тело у 304. Его нет по стандарту, ответ несёт только заголовки, и автотест, разбирающий тело, падает на исправном сервисе.

Третье: жёстко ожидают 200 в тесте, который гоняется повторно тем же клиентом с кэшем. Тест становится плавающим: первый прогон зелёный, второй красный, причина каждый раз ищется заново.