MCP 2026-07-28 за HTTP-балансировщиком: маршрутизация и безопасная область действия кэша

Что это

По состоянию на 25 октября 2026 года. MCP 2026-07-28 позволяет каждому HTTP-запросу передавать контекст, необходимый для независимой обработки. Перед изменением правил шлюза заново проверьте спецификации Streamable HTTP, кэширования и инструментов для нужной редакции. Обычная балансировка нагрузки и корректное кэширование результатов требуют отдельных решений при развёртывании.

Ядро протокола больше не требует транспортных сессий. Для состояния приложения, сохраняемого между запросами, по-прежнему нужны явные идентификаторы и подходящее хранилище. Ответ на запрос может быть потоковым; отсутствие состояния не означает, что каждое соединение будет коротким.

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

RFC 9111 определяет ключи обычного HTTP-кэша на основе HTTP-метода и целевого URI, с учётом дополнительных различий там, где они заданы. Операции MCP используют общую конечную точку POST, а их метод и параметры находятся внутри JSON. Отсюда следует: обычный кэш с ключом только по /mcp не может безопасно различать эти операции. Поле JSON ttlMs не является HTTP-заголовком Cache-Control и не настраивает прокси автоматически.

Списки инструментов могут зависеть от авторизации, но не должны зависеть от истории соединения. Если доступный набор не меняется, рекомендуется детерминированный порядок. Ни одно из этих свойств не делает каталог, отфильтрованный по правам доступа, общедоступным.

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

• Сохраняйте и проверяйте метаданные маршрутизации. Передавайте MCP-Protocol-Version и Mcp-Method; для tools/call, resources/read и prompts/get обязателен Mcp-Name. Серверы, обрабатывающие тело запроса, обязаны отклонять несовпадения или отсутствие обязательных заголовков с HTTP 400 и HeaderMismatch (-32020). Перед сравнением декодируйте имена по указанным правилам кодирования. Не доверяйте этим заголовкам, дублирующим данные тела, при обработке старого протокола, где нет соответствующего требования проверки.
• Не помещайте чувствительные входные данные в заголовки маршрутизации. Схемы инструментов могут предоставлять параметры через x-mcp-header; спецификация инструментов рекомендует не помечать таким образом пароли, токены и персональные данные, поскольку они видны промежуточным узлам. Маршрутизируйте по разрешённым метаданным и сохраняйте авторизацию непосредственно перед выполнением.
• Сохраните потоковую передачу. Поддерживайте ответы JSON и SSE, отключите мешающую работе буферизацию ответов и проверьте поведение тайм-аутов простоя. Спецификация транспорта рекомендует X-Accel-Buffering: no для SSE и комментарии keep-alive для длительных потоков. Не настраивайте возобновление через Last-Event-ID для этой редакции и не кэшируйте потоки подписок.
• Ограничьте набор кэшируемых результатов. Указания по кэшированию обязательны для завершённых результатов обнаружения, получения списков инструментов, промптов, ресурсов и шаблонов ресурсов, а также чтения ресурсов. Промежуточные результаты input_required и запросы с inputResponses или requestState кэшировать запрещено. Не считайте выполнение инструмента пригодным для кэширования лишь на основании описания, что он только читает данные.
• Обеспечивайте свежесть и изоляцию независимо. ttlMs отсчитывает миллисекунды с момента получения; ноль означает немедленное устаревание. Соответствующие уведомления об изменениях аннулируют ещё свежие записи. public разрешает совместное использование только данных, не относящихся к конкретному пользователю; private ограничивает повторное использование одним контекстом авторизации, в том числе требует отдельного кэша для другого токена. Включайте в ключ записи сервер, протокол, метод и параметры, влияющие на результат; различайте отдельные страницы при пагинации.
• Кэшируйте результаты, а не устаревшие оболочки сообщений. Посредник с поддержкой MCP обязан возвращать JSON-RPC ID текущего запроса. Сохраняйте исходный срок свежести, не продлевая его при попадании в кэш. В обычном HTTP-прокси оставьте кэширование POST отключённым, если поведение MCP не реализовано и не проверено явно. Там, где хранение необходимо запретить, помимо политики приложения используйте HTTP-директиву no-store; один лишь private допускает хранение в частном кэше.
• Проверяйте с изолированными тестовыми учётными записями. Предлагаемые проверки в тестовой среде: чередуйте экземпляры, получайте один и тот же список с разными правами, измените каталог, дождитесь истечения срока записи и повторно используйте допустимый результат с другим идентификатором запроса. Подтвердите своевременную доставку потока и отсутствие повторного использования данных одного пользователя другим.

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

TTL указывает срок свежести, но не гарантирует неизменность данных. Маршрутизация по заголовку не является аутентификацией. Успешное распределение запроса балансировщиком не доказывает безопасность повторных попыток для действий с побочными эффектами. При включении оптимизаций инфраструктуры явно определяйте эти решения на уровне приложения.