Кратко

  • 201 Created означает, что принимающий CDN создал ресурс триггера. Это не подтверждение завершённой очистки, инвалидации или предварительного размещения.
  • После принятия запроса транзитный CDN обязан преобразовать синхронный HTTP-отказ следующего CDN в асинхронное описание Error.v2 в собственном ресурсе состояния.
  • PID источника можно не раскрывать. Завершение, отмена, счётчики, возврат узлов и результат у пользователя требуют разных доказательств.

Узел вернулся после зелёного статуса

Представим, что CDN A поручает B удалить контент. B проверяет запрос, создаёт ресурс и возвращает 201 Created. Затем B передаёт операцию C. C не поддерживает один из элементов и отвечает 400 Bad Request.

На стороне B ресурс существует. На стороне C ресурс не создан. Первый ответ не становится ложным, но и не отвечает на вопрос, удалён ли контент по всей задействованной цепочке.

Редакция 20 CDNI Control Interface / Triggers 2nd Edition датирована 2 сентября 2026 года. Datatracker IETF показывает действующий проект рабочей группы CDNI в состоянии WG Document. При утверждении он заменит RFC 8007. Сейчас это не RFC, не решение IESG, не отчёт о реализации и не свидетельство о работе конкретного провайдера.

По сравнению с редакцией 19 значительно расширены обработка и передача ошибок. Новость не в самом действии purge, а в том, как отказ после принятия сохраняется для вышестоящей стороны.

Прошлый HTTP-ответ нельзя заменить

Если B заранее обнаруживает неверный формат, отсутствие прав или неподдерживаемый им элемент, он возвращает 4xx и не создаёт ресурс. После ответа B транзакция между A и B завершена. Поздний 4xx/5xx от C уже не может стать тем HTTP-статусом, который раньше получил A.

Поэтому B должен превратить отказ C в Error.v2 Description и поместить его в массив ошибок собственного ресурса. Асинхронный сбой C после принятия идёт тем же путём. A увидит failed и, например, eunsupported только при последующем опросе.

У C это был прямой отказ. У A — более позднее сообщение B. Система, которая сохраняет лишь 201, теряет сбой. Система, которая оставляет лишь итоговый код, теряет последовательность и происхождение.

B вправе добавить CDN Provider ID сети C, но не обязан. Можно указать собственный PID и скрыть фактическое место отказа. Реестры параметров CDNI IANA стандартизируют словарь, однако не обязывают раскрывать всех коммерческих участников.

Конечное состояние относится к известному графу

Обычный цикл идёт от pending к active, затем к complete или failed. Транзитный CDN не вправе сообщать complete, пока работа не завершена у него и у всех нижестоящих CDN. Если он сам или хотя бы одна ветвь сообщает processed, вверх также передаётся processed.

Processed честно обозначает предел видимости: запрос принят, но дальнейших обновлений не будет. Это не скрытая форма завершения. Уникальные UUID по рекомендации RFC 9562 защищают идентичность ресурса и исключают повторное использование URI, но не удостоверяют действие.

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

Сумма сознательно содержит повторы

В редакции 20 появились накопительные показатели объектов, узлов и байтов. Их рекомендуют суммировать по локальным узлам и каскаду, не удаляя повтор, когда один объект обработан в нескольких местах. Это индикаторы аномально большого или малого объёма.

Десять тысяч операций не обязательно означают десять тысяч уникальных объектов. Ноль тоже не равен неудаче: purge или invalidate без совпадений может успешно завершиться. Для оценки нужны определение счётчика, правило повторов, ожидаемая область и отдельное наблюдение пользовательского пути.

Отмена не останавливает уже прошедшее время

Фактическая поддержка отмены необязательна. Пока запрос A обрабатывается, увиденный ранее pending может стать active. Работа active или processed способна завершиться раньше остановки. Cancelling доказывает, что остановка выполняется, но не что эффекты прекратились.

Удаление стирает ресурс состояния, после чего URI отвечает 404 Not Found. Проект советует отменять, а не удалять, если A ещё нужен конечный статус. 204 No Content относится к записи наблюдения, а не к обратному исполнению операции.

Набор данных также разделён временем. Purge и invalidate обязаны покрывать данные, полученные до active, и должны охватывать уже идущую загрузку. Поздние данные предполагается не затрагивать, но вышестоящей стороне запрещено считать такую границу всегда достижимой. Без явного порядка немедленное размещение замены может попасть под предыдущую очистку.

Контекст задают постановка задачи в RFC 6707, архитектура интерфейсов в RFC 7336 и требования управления в RFC 7337. RFC 9110 определяет HTTP. Но успешный код остаётся доказательством только своей операции.

Возвращающийся узел — отдельный сценарий

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

Такой уровень абстракции удобен, но доверие переходит к процедуре согласования провайдера. Терминальный статус A не был прямой проверкой отсутствовавшего узла. После его возврата нужен новый тест, чтобы старое содержимое не появилось снова.

В diamond-топологии разные пути и задержки могут принести конфликтующие метаданные; проект считает это ошибкой конфигурации. PID помогает обнаруживать циклы, но не гарантирует раскрытия цепочки.

Протокол улучшает журнал. Он не превращает журнал в наблюдение каждого результата.