MCP 2026-07-28: stateless-ядро, MRTR и маршрутизация по заголовкам

Аннотация

28 июля 2026 года Model Context Protocol получил ревизию 2026-07-28 — крупнейшее изменение спецификации с момента запуска. Протокол перестал быть stateful: исчезли обмен initialize/initialized и заголовок Mcp-Session-Id, а server-to-client запросы (elicitation, sampling, roots) переехали в схему Multi Round-Trip Requests¹². Для того, кто держит MCP-сервер сам, это меняет не набор инструментов, а операционную модель: вместо sticky sessions, общего хранилища сессий и разбора JSON-тела на шлюзе остаётся обычная HTTP-нагрузка, которую можно поставить за round-robin балансировщик²³.

Разбор собран по первичным документам: тексту спецификации и её changelog, SEP-предложениям, документации SDK и release notes, — плюс независимые разборы от вендоров шлюзов, платформы, security-компании и практический гайд по миграции. Данные на 2026-10-19. Независимых замеров latency и throughput до и после миграции в открытом доступе нет, поэтому все числа ниже взяты из спецификации и документации, а не из бенчмарков.

Введение

Актуальность. MCP перестал быть протоколом для локального stdio-процесса: по данным авторов спецификации, суммарные загрузки Tier 1 SDK приближаются к половине миллиарда в месяц, а TypeScript- и Python-SDK перешли порог в миллиард скачиваний¹. На такой нагрузке транспортная модель начинает значить больше, чем удобство API.

Спецификация делит протокол на базовый уровень, версионирование, паттерны сообщений, авторизацию, серверные и клиентские возможности и утилиты, причём базовый протокол, версионирование и паттерны обязаны поддерживать все реализации⁴. Ревизия меняет именно этот слой, а не набор функций.

Цель — разобрать механику ревизии 2026-07-28 и ответить на практический вопрос: что конкретно нужно поменять в self-hosted MCP-сервере и в инфраструктуре перед ним, а что можно не трогать. Границы: расширения MCP Apps и Skills over MCP упоминаются только как контекст, производительность не измеряется, а сравнение с альтернативными протоколами (A2A, AT Protocol) выходит за рамки текста.

Как сессия мешала масштабированию

В ревизии 2025-11-25 вызов инструмента по Streamable HTTP начинался с handshake: клиент отправлял initialize, сервер заводил сессию и возвращал Mcp-Session-Id, который все последующие запросы обязаны были повторять². Формально это выглядело как мелочь, но именно идентификатор привязывал клиента к тому инстансу, который сессию создал²⁵.

Авторы предложения SEP-1442 «Make MCP Stateless (by default)» описали последствия прямым текстом: «A simple stateless load balancer (e.g. L4/L7 round-robin) cannot be used, as it would route a client’s requests to different backend servers, none of which would have the correct session state»³. Дальше по цепочке идут три издержки, знакомые любому, кто выводил stateful-сервис в прод: sticky sessions на балансировщике, общий store сессий с сетевой задержкой на каждый запрос и потеря всей сессии при рестарте одного инстанса³⁵.

Impediment to Scalability: The most critical issue is the difficulty of load balancing stateful MCP.³

Показательна и форма: SEP-1442 подписан пятью авторами — Jonathan Hefner, Mark Roth, Shaun Smith, Harvey Tuch и Kurtis Van Gent³. Это не жалоба одного пользователя, а согласованная позиция, и касается она транспортной модели, а не удобства API.

Stateless-ядро: что убрали и что поставили на место

Ревизия удаляет initialize/initialized (SEP-2575) и заголовок Mcp-Session-Id вместе с самим понятием протокольной сессии (SEP-2567)⁶². Взамен каждый запрос обязан быть самоописывающим: в _meta должны присутствовать io.modelcontextprotocol/protocolVersion и io.modelcontextprotocol/clientCapabilities, а клиент «SHOULD» присылать io.modelcontextprotocol/clientInfo⁷. Запрос без обязательных полей считается некорректным: сервер обязан ответить JSON-RPC ошибкой -32602 и HTTP 400 Bad Request⁷.

Спецификация формулирует принцип жёстко: сервер не должен выводить контекст из предыдущих запросов на том же соединении, а состояние, живущее дольше одного запроса, обязано передаваться явным идентификатором⁷.

Servers MUST NOT rely on prior requests over the same connection to establish context (e.g., capabilities, protocol version, client identity). Every request supplies this metadata in its _meta field.⁷

Вместо handshake появился RPC server/discover, который серверы обязаны реализовать: он возвращает supportedVersions, capabilities, serverInfo и опциональные instructions⁸. Вызывать его клиенту не обязательно — можно сразу отправить любой запрос и обработать ошибку версии, — но он удобен в двух случаях: показать пользователю возможности сервера одним запросом и детектировать эру сервера на stdio, где нет HTTP-статусов для fallback⁸⁹.

Согласование версии стало пошаговым, а не сессионным: если сервер не поддерживает запрошенную версию, он возвращает UnsupportedProtocolVersionError (-32022) со списком поддерживаемых, а клиент выбирает общую версию и повторяет запрос⁹. Матрица совместимости в спецификации перечисляет шесть комбинаций «modern/legacy/dual-era» клиента и сервера; ключевой практический вывод — legacy-клиент против modern-сервера не работает и не имеет механизма «fall-forward», поэтому modern-серверу рекомендуется перечислять поддерживаемые версии в тексте ошибки на initialize⁹.

Для оператора это означает ровно то, ради чего всё затевалось: рестарт инстанса больше не убивает диалог, а запросы можно раскладывать round-robin без общего хранилища²¹⁰. Важная оговорка: stateless только протокол, а не приложение. Авторы спецификации предлагают явные handle’ы — инструмент возвращает basket_id, модель передаёт его аргументом в следующий вызов, — и считают такой вариант не компромиссом, а улучшением: «The model can compose handles across tools, reason about them, and hand them off between steps»².

MRTR: server-to-client запросы без открытого потока

До ревизии сервер, которому нужно было спросить пользователя о подтверждении, отправлял elicitation/create, sampling/createMessage или roots/list по удерживаемому SSE-потоку¹¹¹. В stateless-мире удерживать поток негде, поэтому введён паттерн Multi Round-Trip Requests (SEP-2322): сервер отвечает результатом с resultType: "input_required", внутри которого лежат inputRequests (карта запросов с серверными ключами) и опциональный requestState, а клиент повторяет исходный вызов, добавляя inputResponses и тот же requestState¹¹.

Правила узкие и их стоит знать наизусть. Отправлять InputRequiredResult разрешено только на prompts/get, resources/read и tools/call; на любые другие запросы — запрещено¹¹. В ответе обязан быть хотя бы один из inputRequests или requestState, а запросы внутри inputRequests не должны требовать возможностей, которые клиент не объявил¹¹. Если серверу нужна возможность, отсутствующая в clientCapabilities, он возвращает MissingRequiredClientCapabilityError (-32021) с перечнем недостающего и HTTP 400⁷.

Самое интересное — requestState. Это непрозрачная строка, которую клиент возвращает как есть, и спецификация прямо предупреждает, что сервер обязан считать её подконтрольной атакующему: при влиянии на авторизацию или доступ к ресурсам её целостность нужно защищать (HMAC или AEAD) и отклонять при провале проверки¹¹. Рекомендуемый набор полей внутри — аутентифицированный principal, короткий TTL и идентификатор исходного запроса с дайджестом параметров; при этом отдельно оговорено, что эти меры не дают гарантии однократности, и сервер, которому нужно «ровно один раз», должен обеспечивать это сам¹¹.

Побочный, но полезный эффект — SEP-2260: server-to-client запросы теперь разрешены только пока сервер обрабатывает активный клиентский запрос². Пользователя больше не могут спросить «из ниоткуда», и каждая elicitation трассируется к действию, которое он или его агент инициировали².

Цена схемы — дополнительные round-trip’ы. Каждый вопрос пользователю — это новый HTTP-запрос с полным _meta, а не сообщение в уже открытом канале. Для интерактивных подтверждений это нормально, для сценариев с десятком уточнений — заметно; и именно поэтому результаты, полученные повторным запросом с inputResponses или requestState, запрещено кэшировать¹².

Транспорт: три заголовка и их цена

Streamable HTTP в этой ревизии требует MCP-Protocol-Version на каждом POST, причём значение обязано совпадать с io.modelcontextprotocol/protocolVersion в теле: расхождение — 400 и ошибка HeaderMismatch (-32020)¹³. Дополнительно обязательны Mcp-Method (все запросы) и Mcp-Name (tools/call, resources/read, prompts/get)¹³¹⁴.

Смысл прост: промежуточный слой — балансировщик, rate limiter, WAF — может принимать решения по заголовкам, не разбирая JSON-RPC тело¹¹⁵. Tigera перечисляет, что это открывает: per-tool rate limiting для дорогих инструментов, маршрутизация resources/read на read-оптимизированные реплики, дешёвые ранние отказы и видимость операций MCP в существующих access-логах¹⁵.

Второй, куда менее очевидный механизм — x-mcp-header. Сервер может пометить примитивный параметр инструмента этим свойством в inputSchema, и конформный клиент обязан продублировать значение аргумента в заголовок Mcp-Param-{Name}¹³. Ограничения прописаны детально: только string, integer или boolean (тип number запрещён), целые в безопасном диапазоне JavaScript, параметр должен быть статически достижим только по цепочке properties, имя — валидный HTTP-токен, переводы строк запрещены, не-ASCII кодируется base64¹³. Клиент, встретивший нарушение, обязан исключить инструмент из результата tools/list¹³; Python SDK 2.3.0 сделал следующий шаг и падает при регистрации такого инструмента с InvalidSignature, называя инструмент и причину¹⁶.

Практический пример конфигурации шлюза, который маршрутизирует по операции, а не по телу (домены обезличены):

location /mcp {
    # маршрутизация по заголовку операции, без разбора JSON-RPC тела
    set $mcp_pool tools_backend;
    if ($http_mcp_method = "resources/read") { set $mcp_pool read_backend; }

    proxy_buffering off;         # иначе SSE-события залипают в буфере nginx
    proxy_read_timeout 3600s;    # для долгих subscriptions/listen
    proxy_pass http://$mcp_pool;
}

Оговорка, которую легко пропустить: отключить буферизацию должен сам сервер, отдавая в SSE-ответе заголовок X-Accel-Buffering: no; без этого nginx накапливает события и ломает их доставку¹³.

Почему «любой балансировщик» — не вся правда

Заголовки действительно дают дешёвую маршрутизацию, но из этого не следует, что политику безопасности можно строить только на них. Кристиан Поста из agentgateway приводит конкретный сценарий: шлюз разрешает агенту единственный «безопасный» инструмент echo по allowlist заголовков, а тот же сервер экспонирует printEnv. Запрос с Mcp-Name: echo и телом tools/call для printEnv пройдёт header-only прокси и выполнится на бэкенде¹⁷.

The proxy sees Mcp-Name: echo, decides “echo is safe,” and forwards. The header said echo. The body ran printEnv and dumped its environment variables, secrets and all.¹⁷

Спецификация этот класс атак закрывает: сервер, обрабатывающий тело, обязан сверить заголовки с телом и вернуть HeaderMismatch¹⁴. Но полагаться на то, что «сервер за моей спиной проверит инвариант, на котором построено моё решение», — ровно та ошибка, из которой рождаются CVE¹⁷. Tigera формулирует компромисс аккуратно: заголовок — это заявление, которое сервер в итоге проверит, а тело остаётся истиной; быстрый отказ по заголовку безопасен, а разрешение чувствительной операции требует разбора тела¹⁵.

Второе ограничение header-only подхода — каталог инструментов. tools/list — это тело ответа, и прокси, не читающий тело, не может отфильтровать недоступные инструменты: пользователь с правами на 2 инструмента из 100 увидит все 100, а модель будет раз за разом вызывать запрещённые¹⁷. Отсюда практическое правило: заголовки — для маршрутизации, метрик и ранних отказов; авторизация по инструменту — на уровне, который видит аргументы и identity.

Кэширование каталога и стабильность префикса промпта

Результаты server/discover, tools/list, prompts/list, resources/list, resources/templates/list и resources/read обязаны нести ttlMs и cacheScope (SEP-2549)¹²¹. ttlMs — подсказка свежести в миллисекундах, по семантике близкая к Cache-Control: max-age; 0 означает «сразу устарело», отсутствие поля клиент трактует как 0, отрицательное значение игнорируется¹². cacheScope принимает public или private: первое разрешает кэшировать любому посреднику, второе — только в пределах контекста авторизации, и общий кэш между разными токенами запрещён¹².

Ключ кэша — метод плюс влияющие на результат параметры (например, uri для resources/read или cursor для страницы списка); ответы на повтор запроса с inputResponses/requestState кэшировать нельзя¹². Уведомления и TTL дополняют друг друга: listChanged работает как немедленная инвалидация, TTL — как способ не дёргать сервер между изменениями¹².

Для self-hosted сервера тут два практических следствия. Первое — экономия: каталог инструментов меняется редко, а агент запрашивает его постоянно, и без кэша каждый цикл платит лишний round-trip и лишние токены¹⁵. Второе — риск: описание инструмента и его JSON Schema напрямую влияют на то, какой инструмент выберет модель, поэтому «отравленная» запись живёт ровно ttlMs и делится ровно настолько, насколько разрешает cacheScope¹⁸. Этот риск обычно недооценивают: сервер, ставящий ttlMs: 3600000 и cacheScope: public на персонализированный список, сам создаёт инцидент.

Отдельно спецификация просит детерминированный порядок инструментов в tools/list — это стабилизирует префикс промпта и повышает попадания в upstream prompt cache⁶¹².

Подписки, ретраи и отсутствие resumability

Долгоживущие уведомления переехали в subscriptions/listen: клиент открывает один запрос с фильтром (toolsListChanged, promptsListChanged, resourcesListChanged, resourceSubscriptions), сервер первым сообщением присылает notifications/subscriptions/acknowledged с фактически принятым набором, а все последующие уведомления несут io.modelcontextprotocol/subscriptionId, равный JSON-RPC id этого запроса¹⁹. Это заменяет и HTTP GET-эндпоинт, и resources/subscribe, и roots/list_changed⁶¹⁹.

Цена — потеря возобновляемости. Last-Event-ID и SSE event id удалены: оборванный поток теряет запрос, и клиент обязан переотправить его как новый, с новым id⁶¹³. В core-протоколе нет ключа идемпотентности, поэтому вопрос «задублирует ли ретрай платёж, деплой или удаление» целиком зависит от того, написан ли инструмент так, чтобы это заметить¹⁸. Для self-hosted это прямое требование к дизайну инструментов: идемпотентность через клиентский ключ в аргументах, а не надежда на транспорт.

Мелочи, которые ломают продакшн чаще, чем кажется: серверу рекомендуется периодически отправлять SSE-комментарий (:) как keep-alive на тихих подписках, а при реконнекте на stdio клиент обязан заново отправить subscriptions/listen, потому что состояние подписок между переподключениями не сохраняется¹⁹.

Tasks: длинные операции как расширение

Экспериментальные задачи вынесены из ядра в официальное расширение io.modelcontextprotocol/tasks (SEP-2663): блокирующий tasks/result заменён на polling через tasks/get, добавлен tasks/update для ввода от клиента, tasks/list удалён, а сервер может вернуть задачу без отдельного opt-in на каждый запрос⁶²⁰.

Механика: сервер возвращает CreateTaskResult с resultType: "task", taskId, начальным статусом, TTL и рекомендованным интервалом опроса; задача создаётся durably до отправки ответа; клиент опрашивает tasks/get, а в состоянии input_required получает inputRequests и отвечает через tasks/update; статусы — working, input_required, completed, failed, cancelled²⁰. Мотивация в документации сформулирована без маркетинга: удерживать соединение до конца операции мешают таймауты посредников, а task id переживает рестарт клиента²⁰.

Для оператора это означает, что «долгая работа» больше не требует ни открытого потока, ни отдельного хранилища сессий — но требует настоящего хранилища задач с TTL и идемпотентным созданием.

Авторизация: iss, CIMD и привязка к issuer

Авторизация в MCP по-прежнему опциональна и строится на OAuth 2.1; сервер обязан реализовать Protected Resource Metadata (RFC 9728), а клиент — использовать её для поиска authorization server²¹. Ревизия добавила три вещи, важные именно для самостоятельного хостинга.

Первое — обязательная проверка iss по RFC 9207: authorization server должен возвращать параметр iss, а клиент обязан сверить его с запомненным issuer до обмена кода¹²¹. Это закрывает класс mix-up атак, описанный в RFC 9207: без iss клиент, работающий с несколькими authorization server’ами, не может понять, кто именно выпустил ответ²².

The iss parameter serves as an effective countermeasure to “mix-up attacks”.²²

Второе — смена модели регистрации клиентов: Dynamic Client Registration формально депрецирован, вместо него предлагаются Client ID Metadata Documents (CIMD)²³²⁴. DCR продолжает работать для обратной совместимости, но помечен как подлежащий удалению в будущей ревизии¹. Практический побочный эффект, знакомый всем, кто писал CLI-клиент: при DCR нужно указывать application_type, иначе authorization server отклоняет localhost-redirect’ы для desktop и CLI приложений (SEP-837)¹²⁴.

Третье — привязка учётных данных к issuer: клиент обязан хранить их с ключом по идентификатору authorization server, не переиспользовать с другим и регистрироваться заново при смене сервера (SEP-2352)¹⁶.

Отдельный класс риска, который ревизия не отменяет, описан в Security Best Practices: MCP proxy server со статическим client ID, динамической регистрацией клиентов и consent-cookie на стороне стороннего authorization server открывает classic confused deputy — код выдаётся без повторного согласия пользователя²⁵. Stateless-топология такие прокси не запрещает, а иногда и поощряет.

Для self-hosted сборки это обычно означает: свой authorization server должен отдавать iss, а клиентская часть — уметь CIMD или хотя бы не ломаться на отсутствии DCR. Практический минимум для своей сборки: убедиться, что authorization server возвращает iss в authorization response, и что клиент сверяет его с записанным issuer; для самописных серверов это требует явной доработки.

Миграция: dual-era, SDK и операционный чек-лист

Спецификация допускает dual-era сервер: запрос с modern _meta обслуживается stateless, а initialize переключает на legacy-семантику, и оба режима могут работать на одном эндпоинте⁹. Это единственный способ не сломать старых клиентов, потому что legacy-клиент не умеет откатываться вперёд и увидит только ошибку⁹.

В SDK картина разная. TypeScript SDK v2 разложен на отдельные пакеты @modelcontextprotocol/client и @modelcontextprotocol/server; для переименований есть codemod npx @modelcontextprotocol/codemod@latest v1-to-v2 ., но adoption самой ревизии 2026-07-28 автоматизировать нельзя — документация прямо называет его архитектурным изменением (createMcpHandler, multi-round-trip, versionNegotiation)²⁶. Cloudflare в Agents SDK v0.20.0 перевёл серверы на фабрику, создающую изолированный экземпляр на запрос, объявил McpAgent deprecated и feature-frozen и добавил isLegacyRequest() для постепенного перевода трафика²⁷.

Python SDK 2.3.0 показывает, как выглядит зрелость на практике: невалидный x-mcp-header теперь падает при регистрации инструмента, клиент после HeaderMismatch (-32020) перезапрашивает tools/list и повторяет вызов один раз, появился лимит max_sse_event_size (по умолчанию 1 MiB на событие), а MCPServer(subscriptions=False) отключает subscriptions/listen и честно объявляет listChanged и subscribe выключенными¹⁶.

Операционный чек-лист, который следует из перечисленного:

• Инстансы без памяти. Любой узел обслуживает любой запрос; in-process кэши и счётчики не должны быть привязаны к соединению⁷.
• Состояние — в БД по handle. basket_id/job_id в аргументах инструмента, TTL и владелец в хранилище, а не в памяти процесса².
• Идемпотентность инструментов. Ключ идемпотентности в аргументах обязателен для платящих и разрушающих операций: транспорт ретраит без гарантий¹⁸.
• Валидация на двух уровнях. Шлюз разбирает тело для чувствительных операций, сервер проверяет HeaderMismatch; метрика по -32020 — индикатор атак или багов клиента¹⁴¹⁷.
• Кэш по правилам. ttlMs и cacheScope выставляются осознанно, персонализированные списки — только private¹².
• Наблюдаемость. traceparent/tracestate/baggage в _meta стандартизованы, так что трейс проходит от хоста через шлюз в сервер⁶².

Депрекации: что реально даёт двенадцать месяцев

Политика жизненного цикла (SEP-2596) впервые зафиксирована формально: депрецированная функция остаётся в спецификации, новые реализации не должны её внедрять, а самая ранняя точка удаления — первая ревизия, выпущенная не раньше чем через двенадцать месяцев²³¹. В реестре сейчас шесть позиций: Roots, Sampling и Logging (миграция — параметры инструментов и OpenTelemetry вместо logging), DCR (миграция — CIMD), includeContext в sampling и транспорт HTTP+SSE (миграция — Streamable HTTP)²³.

Здесь и возникает главное расхождение в трактовках. Блог и часть гайдов читают это как «у вас есть год на всё»¹⁵, а security-разбор Equixly — иначе: «The initialize handshake and Mcp-Session-Id are gone, not deprecated. Older clients keep working only if you run the old path alongside the new one»¹⁸. Обе формулировки верны, но говорят о разном: двенадцатимесячное окно относится к фичам в состоянии Deprecated, а handshake и сессия — не депрецированы, а удалены как breaking change, и совместимость обеспечивается исключительно dual-era реализацией⁹²³. Для планирования это принципиально: год есть у Roots/Sampling/Logging, а на stateless-путь нужно переходить сейчас, если вы хотите обслуживать клиентов 2026-07-28.

Дискуссионные вопросы и противоречия

Stateless ≠ проще. Официальная позиция: сессии убраны, и это снимает sticky routing и общий store¹². Критическая: состояние не исчезло, оно переехало в приложение и в базу, а handle теперь проходит через контекст модели и через всё, что может на этот контекст влиять¹⁸. Примирение простое: протокол перестал быть местом хранения состояния, но не отменил необходимость его хранить; выигрыш — в операционной простоте, а не в отсутствии состояния.

«Любой L7-балансировщик». Solo.io и документация подчёркивают горизонтальное масштабирование и round-robin¹⁰²; agentgateway возражает, что header-only прокси делает атаку вида «заголовок echo, тело printEnv» тривиальной, а фильтрацию tools/list — невозможной¹⁷. Обе позиции совместимы: маршрутизация по заголовкам — да, авторизация по заголовкам — нет. Tigera добавляет третий нюанс: заголовки дают дешёвые ранние отказы, но разрешение чувствительной операции всё равно требует тела¹⁵.

Безопасность и statelessness. В релизных материалах авторизация описана как «hardened»¹, а Equixly фиксирует, что statelessness «does not make your deployment more secure»: найденные в популярных MCP-серверах уязвимости — обычные command injection и path traversal, а не дефекты протокола¹⁸. Меняются места, где принимается решение (шлюз, заголовки, requestState), а не качество кода за интерфейсом.

Порядок и кэш. Детерминированный порядок tools/list подаётся как улучшение prompt-кэша⁶, но кэшируемые описания инструментов — одновременно канал влияния на выбор инструмента моделью¹⁸. Один и тот же ttlMs может экономить запросы и продлевать жизнь отравленной записи; спецификация даёт механизм, но не даёт политики.

Недостаточность данных

Публичных измерений latency и throughput «до/после» для реального сервера найти не удалось; все заявления о выигрыше остаются аргументами об архитектуре, а не измерениями. Нет открытых данных о доле серверов, уже обслуживающих 2026-07-28, — есть только косвенные признаки (релизы SDK, changelog платформ)²⁶²⁷. Не опубликовано ни одного разбора инцидента, связанного с HeaderMismatch, отравлением кэша каталога или злоупотреблением requestState: класс атак описан, эксплуатация — нет. Независимого аудита реализации x-mcp-header в SDK на момент написания тоже нет, поэтому утверждение «валидация работает» опирается на код и release notes, а не на тесты третьей стороны¹³¹⁶.

Заключение

Ревизия 2026-07-28 — это перевод MCP из «протокола с сессией» в «протокол с самодостаточным запросом». Механика складывается из четырёх частей: per-request _meta и server/discover вместо handshake, MRTR вместо server-to-client запросов по открытому потоку, три обязательных заголовка и кэшируемые списки, плюс отдельная линия ужесточения OAuth (iss, CIMD, привязка к issuer)^2111321.

Практический вывод для self-hosted сервера: миграция окупается не «модностью», а снятием целого класса эксплуатационных проблем — sticky sessions, общего store сессий, потери диалога при рестарте. Но она требует дисциплины в трёх местах, где раньше всё делал протокол: явные handle’ы вместо скрытого состояния, идемпотентность инструментов вместо надежды на транспорт и осознанные ttlMs/cacheScope вместо «закэшируем на час»²¹⁸¹².

Дальше стоит смотреть на три вещи: как быстро Tasks-расширение станет стандартом для CI- и batch-сценариев²⁰, появится ли в core ключ идемпотентности, и как будут сосуществовать header-based маршрутизация и body-aware авторизация в реальных шлюзах¹⁷¹⁵. До появления независимых замеров любые утверждения о выигрыше в latency стоит считать гипотезой.

Quality Metrics