Кэшируется ли POST-запрос

Кэширование POST-Surrogate

Короткий ответ: стандартный HTTP-кэш браузера или промежуточных прокси НЕ кэширует POST-запросы по умолчанию. Однако существуют механизмы, которые могут сделать ответы на POST-запросы условно кэшируемыми при соблюдении определенных условий.

Почему POST обычно не кэшируется?

Согласно спецификации HTTP (RFC 7231), методы запроса делятся на «безопасные» (safe) и «идемпотентные» (idempotent).

• GET и HEAD считаются и безопасными, и идемпотентными. Их можно кэшировать, так как они предназначены для получения данных без изменения состояния сервера.
• POST НЕ является ни безопасным, ни идемпотентным по умолчанию. Он предназначен для отправки данных, которые могут изменить состояние сервера (создание заказа, отправка формы).

Основные причины некэшируемости POST по умолчанию:

1. Семантика метода: POST предполагает действие с побочными эффектами. Кэширование такого ответа и его повторное использование для другого запроса может привести к дублированию операций (например, двойному списанию средств).
2. Отсутствие ключа кэширования: Для кэширования нужен ключ, обычно это метод запроса и его полный URL. У GET-запросов параметры — часть URL. Тело POST- запроса не является частью URL, что делает создание уникального ключа сложным для стандартных кэшей.

Когда POST может быть кэширован?

Несмотря на стандарты, кэширование POST возможно в двух основных сценариях:

1. Явное указание с помощью заголовков ответа (Cache-Control) Сервер может явно разрешить кэширование, отправив в ответе соответствующие HTTP–заголовки. Это имеет смысл только если POST используется для запросов, не меняющих состояние, например, в API, где POST применяется для сложных запросов с телом (как в GraphQL).

Пример ответа сервера:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: public, max-age=3600

{"data": "результат запроса"}

В этом случае кэш может сохранить ответ, но ключом будет комбинация URL + тело запроса (что реализуется не всеми кэшами).

2. Использование метода POST как семантического GET (Surrogate Key Pattern) В высокопроизводительных архитектурах (например, с использованием CDN или кэширующих прокси типа Varnish) иногда намеренно кэшируют ответы POST. Это делается, когда:

• Тело запроса велико и неудобно помещать в URL GET–запроса.
• Требуется инвалидация кэша по сложным правилам.

В этом случае используют заголовок Surrogate-Key или аналогичный. Кэширующий прокси сохраняет ответ и связывает его с пользовательским ключом, а не с данными запроса. Инвалидация происходит путем очистки всех записей, помеченных этим ключом.

Пример конфигурации для Varnish (VCL):

sub vcl_backend_response {
    if (beresp.status == 200 && bereq.method == "POST") {
        # Разрешаем кэширование POST для определенных путей
        if (bereq.url ~ "^/api/search") {
            set beresp.ttl = 1h;
            set beresp.http.Cache-Control = "public, max-age=3600";
            # Устанавливаем суррогатный ключ для инвалидации
            set beresp.http.Surrogate-Key = "search-results";
        }
    }
}

Практический вывод для QA Automation Engineer

При автоматизации тестирования API и веб-приложений:

1. Не рассчитывайте на кэширование POST-запросов при тестировании через обычные браузеры или стандартные клиенты (например, requests в Python без специальной настройки сессии).
2. Всегда проверяйте заголовки ответа (Cache-Control, Expires). Если сервер явно разрешает кэширование — это может быть багом для критичных операций (платежи, создание сущностей).
3. При тестировании производительности учитывайте, что кэширование POST возможно на уровне CDN или кастомного прокси. Это требует отдельного тестирования сценариев инвалидации кэша.
4. Для идемпотентных операций, которые сейчас используют POST, в современных API часто применяют метод PUT или PATCH, так как они являются идемпотентными и их кэширование более предсказуемо.

Таким образом, в контексте стандартов HTTP — POST не кэшируется. Но в реальных сложных системах, благодаря расширениям и кастомным правилам, его ответы могут быть закэшированы, что является важным нюансом для тестирования.