Кратко
- RFC 5005 прямо называет постраничный фид допускающим потери: набор может меняться во время обхода, поэтому успешные страницы не образуют гарантированно согласованный снимок.
- Архивный фид позволяет собрать логическую историю, но не подтверждает, что клиент дошёл до конца, разрешил конфликты, сохранил состояние и честно показал неполноту.
На учении по восстановлению оператор получает текущий документ, следует по prev-archive и видит тысячи локальных записей. Задание отмечается выполненным: «история восстановлена».
Но RFC 5005 требует различать сам тип источника. Complete feed заявляет, что один документ содержит все записи логического фида. Paged feed делит записи между временными и нестабильными документами. Archived feed соединяет текущий документ подписки с более старыми архивами, которые можно объединить. Семантика смешения этих типов в RFC не определена.
Пагинация принципиально не даёт снимка. Пока клиент идёт по next и previous, издатель может добавить или изменить запись так, что клиент этого не увидит. Поэтому paged feed назван lossy, а результат не следует показывать как согласованный или полный. Набор ответов 200 доказывает отдельные передачи, но не неподвижность всего множества.
Архив даёт более сильную структуру. prev-archive указывает на непосредственно предшествующий архив, next-archive — в обратную сторону, а current — на документ подписки. Содержимое опубликованного архива и его адрес не должны существенно меняться со временем, чтобы ранее обработанный участок можно было считать устойчивым.
Это нормативное ожидание уровня SHOULD, а не криптографическая неизменность. Если старый архив исправлен, клиенты, уже отметившие его обработанным, могут не узнать. Существенное исправление, которое должно дойти до всех, RFC советует снова поместить в текущий документ.
Реконструкция требует конкретного обхода. Клиент загружает ещё не обработанный prev-archive, добавляет записи и повторяет до известного звена, конца без предшественника либо ошибки. Издатель не обязан выдавать все архивы: возможны 403, 404 и 410. Клиент также не обязан всегда хранить или собирать всё, но при неполном результате должен предупредить пользователя.
Для протокола восстановления это означает разные исходы: достигнут самый старый архив; достигнута заранее проверенная точка; произошла ошибка; сработал предел времени, запросов или хранения. Один флаг done стирает различие между ними.
После загрузки остаётся сверка. Среди дубликатов следует выбрать запись с более поздним обновлением. При равных или отсутствующих метках времени приоритет определяет клиент. RFC 4287 задаёт Atom ID, дату и ссылки, но не гарантирует одинаковое решение у разных потребителей. RFC 6721 добавил явную запись об удалении, потому что базовый Atom не сообщал клиенту, что ранее полученный объект исчез.
Маркер fh:complete — отдельное заявление издателя: данный документ представляет полный логический набор. Он не доказывает, что кэш получил актуальные байты, удалил старое состояние, сохранил единый контекст безопасности, правильно отрисовал страницу или повлиял на решение человека.
Квитанция восстановления должна включать:
- идентичность, время и validator текущего документа;
- заявленный тип и фактически увиденный граф ссылок;
- каждый IRI, redirect, ответ, authority, аутентификацию и хэш;
- порядок обхода, повторы, предел ресурсов и причину остановки;
- правила дубликатов, равных меток и удалений;
- ревизию сохранённого состояния, момент отсечения и статус полноты;
- реально показанное предупреждение;
- независимое чтение пользовательского представления.
Это рекомендация по управлению, а не дополнительное требование RFC. Она следует разделению слоёв реальности у Heng Lu: публикация, транспорт, материализованное состояние и наблюдение человека не должны становиться одним фактом без связующих доказательств.
Стандарт не подтверждает работу конкретной платформы, существование полной цепи, событие удаления или реакцию читателя. Два verified errata исправляют пример UUID и термин URI на IRI для Atom-ссылок; граница между возможностью и наблюдаемым результатом остаётся.
Поэтому после учения нужен не вопрос «открылся ли архив», а ответ: какой участок истории восстановлен, до какой точки, при каких ограничениях и какие пробелы по-прежнему видимы.
Источники
- RFC 5005 — Feed Paging and Archiving
- Errata RFC 5005
- RFC 4287 — The Atom Syndication Format
- RFC 6721 — The Atom deleted-entry Element
- Реестр IANA Link Relations
- RFC 9111 — HTTP Caching
- RFC 5005 — канонический текст
- Карточка RFC Editor
- Карточка IETF Datatracker
- История IETF Datatracker
- RFC 5023 — The Atom Publishing Protocol
- RFC 7232 — HTTP Conditional Requests
- RFC 8288 — Web Linking
- RFC 8322 — Resource-Oriented Lightweight Information Exchange
- Heng Lu — Running Code Primary
- Heng Lu — Minimum Initial Specification
- Heng Lu — On Reality Layers
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
