Кратко

  • Необязательная коллекция Complete содержит успешные задания и запросы processed, по которым больше не будет обновлений. Попадание в неё не доказывает общий успех.
  • Отдельное состояние complete требует успешного завершения соответствующих действий, включая затронутые дальнейшие CDN. Посредник не вправе превратить их processed в подтверждённое complete.
  • Ожидаемое время окончания помогает планировать, но не удостоверяет результат. Интерфейс триггеров не требует синхронизации часов между соединёнными CDN.
  • Инвалидация, очистка, предварительная загрузка, отмена и удаление отчёта имеют разные последствия. Следующее действие должно назвать результат, от которого действительно зависит.
  • Сценарий замены ниже — анализ спецификации, не наблюдавшийся дефект поставщика и не измерение распространённости реализации.

Следующая загрузка ждёт не того признака

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

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

Однако отдельное состояние может быть processed. Запрос принят, дальнейших обновлений не будет; это состояние допускается и тогда, когда подтвердить завершение нельзя. Закончился ответ о наблюдении, но не обязательно вопрос о результате.

Ситуация гипотетическая. RFC 8007 прямо позволяет ограниченную отчётность. Здесь рассматривается риск, возникающий, когда другой участник использует это ограничение как более сильную гарантию для собственной зависимой операции.

Это не сообщение об ошибке конкретной CDN. Источники не устанавливают ни массовое применение интерфейса, ни фактически произошедшую потерю материала. Они позволяют проверить, какую уверенность действительно несёт предусмотренный статус.

Наблюдателю важно, поступят ли новые сведения. Владельцу замены важно, завершилась ли очистка, способная повлиять на новые данные. Одна классификация отчёта не отвечает за обе задачи одновременно.

Два окончания в одной коллекции

RFC 8007 опубликован в декабре 2016 года как документ IETF категории Standards Track. Карточка RFC Editor указывает Proposed Standard. Он определяет триггерную часть интерфейса управления CDNI.

Одна сеть запрашивает работу у другой, доставляющей контент от её имени. Можно попросить получить метаданные или содержимое, инвалидировать либо очистить их, а затем проверять состояние. Это не единая система управления всеми коммерческими отношениями, первоначальной настройкой и местными правами доступа.

Принимающая CDN поддерживает коллекцию ресурсов состояния для каждого заявителя. Отфильтрованные представления необязательны. Если они реализованы, общая коллекция должна предоставить их ссылки; нельзя предполагать одинаковые дополнительные представления у любой реализации.

Коллекция с названием Complete объединяет успешно законченные действия и запросы processed без дальнейших обновлений. Название организует жизненный цикл наблюдения, а не добавляет всем элементам одинаковое доказательство успеха.

Отдельное состояние complete означает успешное окончание задания. Processed сообщает о принятии без будущих обновлений, включая случаи, когда окончание невозможно подтвердить. Общая коллекция не устраняет это различие.

Processed не всегда означает провал. Оно также не всегда означает успех, отсутствие работы, остановку выполнения или отсутствие будущих последствий. В первую очередь определена граница того, что партнёр ещё сообщит.

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

Принятие создаёт адрес проверки

При принятии триггера получатель создаёт ресурс состояния и возвращает его расположение с HTTP 201. Заявитель получает ссылку для последующей проверки. Сам ответ не делает запрошенную работу уже совершившимся фактом.

Использовать нужно возвращённую ссылку. Нельзя угадывать структуру URI или превращать примеры в обязательное соответствие между адресами и ресурсами. Однажды использованный URI состояния не должен применяться повторно даже после удаления.

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

Реализация с отслеживанием может сообщать ожидание, активность, затем успех или неудачу. Если отслеживать и сообщать прогресс нельзя, ограничение требуется обозначить через processed и поместить ресурс в Complete. Уместная оценка времени окончания также рекомендуется для планирования.

Иногда новой деятельности вообще не требуется. Очистка может касаться ещё не полученных данных. Предварительная загрузка может запросить уже имеющийся и действительный материал. В таких случаях processed или complete может быть корректным.

Поэтому успешное состояние не измеряет автоматически переданные байты или очищенные устройства. Его значение зависит от типа работы и охвата. Число закрытых ресурсов не заменяет эту информацию.

Каскад не повышает уверенность сам собой

Принимающая CDN может передать доставку дальнейшим сетям. Команда должна дойти до тех, кого может затронуть. Локальное завершение посредника не снимает зависимости от этих результатов.

RFC 8007 запрещает сообщать complete до complete во всех затронутых дальнейших CDN. Если одна из них сообщает processed, промежуточные сети тоже должны сообщать processed, а не заменять отсутствие подтверждения успехом.

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

Ошибка может быть сообщена при возникновении в сети или её продолжении. Ресурс состояния может содержать ошибки для части URL и оставаться активным для других. Описания указывают конкретные запрошенные адреса или шаблоны.

Ссылки в ошибках должны точно совпадать с запросом и не обобщаться до более широкого диапазона. Неудача одной цели не означает неудачу всех. Отсутствие уже сообщённой ошибки по другой цели не доказывает её успех.

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

Требования CDNI в RFC 7337, документе Informational, предусматривали подходящие сведения о завершении и успехе либо неудаче, включая каскады. Интерфейс триггеров также даёт явный язык для ограниченной возможности наблюдать, вместо её сокрытия под общим успехом.

Успех зависит от действия

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

Действующий реестр IANA сохраняет различие. Условие будущего использования — не тот же физический результат, что удаление из хранилища.

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

Очистка и предварительная загрузка могут быть processed, когда работа закончится после возвращения серверов. Если от неё отказались, следует сообщить ошибку. Не всякая конечная классификация отчёта удостоверяет физическое удаление.

Охват ограничен запрошенными данными и отношением распределения. Ни один такой отчёт не доказывает исчезновение всех копий в интернете. Последующее изменение состояния не возвращает уже доставленный получателю материал.

Порядок отправки не определяет удалённое исполнение

Начало и темп работы контролирует принимающая CDN. Очистка и инвалидация должны охватывать данные, полученные до принятия команды. Не следует затрагивать приобретённые позднее, однако заявитель не может рассчитывать на всегда достижимое исключение.

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

Поэтому RFC 8007 рекомендует завершить очистку или инвалидацию до предварительной загрузки замены по тем же URL. При параллельном выполнении новый материал может быть получен и сразу затронут ещё работающей старой командой.

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

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

Владелец контента должен назвать предпосылку. Нужен ли ему подтверждённый успех в определённом охвате? Принимает ли он оценку и её неопределённость по местному соглашению? Независима ли следующая работа от неясной цели? Название Complete не выбирает ответ.

Оценка времени не становится свидетельством

Необязательное etime сообщает, когда принимающая CDN ожидает окончание работы. Оно помогает планировать следующую загрузку. Но не удостоверяет успех при наступлении этого момента.

Времена создания, изменения и ожидаемого окончания определяет сообщающая CDN. Интерфейс не требует синхронизации часов между соединёнными сетями. Сортировка их чисел не восстанавливает сама по себе общую причинную последовательность.

Участники могут местно договориться, как учитывать разные временные основы и неопределённость. Это соглашение не превращает processed в complete. Даже точно согласованные часы не превращают ожидание в полученный результат.

Условные HTTP-запросы уменьшают стоимость наблюдения. RFC 8007 рекомендует ETag для ресурсов и коллекций; семантика HTTP и правила кеширования объясняют инструмент, но не успех действия за ним.

Ответ 304 для неизменившегося processed может быть правильным: представление осталось прежним. Он не даёт подтверждения, которое сторона больше не обещает обновлять. Повышение частоты проверки не расширяет ограниченный договор наблюдения.

Отмена и удаление отчёта не возвращают прошлое

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

Ожидающее задание может начать исполняться раньше обработки отмены. Активное не обязательно остановится сразу. Уже выполненная очистка или получение не обращаются автоматически вспять. Состояние complete или failed нельзя задним числом заменить на отменённое.

Значения в протоколе тоже требуют точности. Проверенное техническое исправление 5053 задаёт cancelling и cancelled; 5054 исправляет ecancelled. Редакционное исправление 5064 отделяет явный пример отмены от удаления ресурса. Русское объяснение не изменяет написание передаваемых значений.

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

Автоматическое хранение также ограничивает окно наблюдения. При удалении старых ресурсов длительность должна быть объявлена. Сохранять конечные отчёты хотя бы двадцать четыре часа рекомендовано, но это не безусловный обязательный минимум. Нужные результаты следует получить до закрытия окна.

Защищённый обмен может передавать ограниченный ответ

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

Коллекции принадлежат своему заявителю и не должны быть видны другим CDN. TLS с проверкой удалённой стороны требуется, если информацию не защищает подходящая альтернатива. Конкретное управление доступом местное; коммерческое доверие остаётся вне определения протокола.

Современные рекомендации TLS заменяют более раннее руководство, на которое ссылался исходный текст. Защищённый канал помогает установить происхождение отчёта, не подтверждая успешное выполнение каждого действия.

Модель CDNI, метаданные и журналирование дополняют доказательства. Успешная доставка или корректная запись в одной точке не удостоверяет состояние всех отключённых и дальнейших систем.

Источники

Первичные документы обосновывают семантические различия. Предложения о решениях — анализ автора, не новые требования стандарта.