Кратко

  • В редакции 04 проекта EPP поверх HTTPS статус HTTP 200 сопровождает любой сформированный ответ EPP после прикладной обработки — и успешный, и ошибочный.
  • Если действительный ответ EPP не получен, а команда могла достичь обработчика, её исход неопределён. Повтор допустим лишь для EoH-клиента, который знает идемпотентную семантику всей команды с расширениями и сохраняет порядок.
  • Реестру и регистратору нужен акт диспозиции команды, связывающий HTTP-попытки, идентификаторы EPP, основание повтора, барьер последовательности и окончательную сверку.

Зелёный HTTP 200 обладает непропорциональной убедительностью. Он закрывает тревогу, улучшает показатель доступности и подталкивает очередь дальше. Но для команды EPP, упакованной в HTTPS, зелёный цвет отвечает только на вопрос о внешней оболочке. Что сделал реестр, сообщает вложенный ответ EPP.

Проект draft-ietf-regext-epp-https-04, опубликованный 3 сентября 2026 года, проводит эту границу прямо. Если запрос дошёл до уровня обработки EPP и тот сформировал ответ, сервер обязан вернуть его с HTTP 200 независимо от успеха или ошибки команды EPP. Успешная доставка ответа не меняет его прикладного содержания.

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

Это не уклонение от решения, а точная граница знания. У клиента нет авторитетного результата EPP, и следы не исключают обработку. Если инфраструктура автоматически переводит неизвестность в ошибку и повторяет POST, она получает право заново воздействовать на объект, не понимая реестровой семантики.

Веб-оболочка не отменяет состояние и порядок

RFC 5730 определяет EPP как протокол XML с состоянием для управления объектами в общем центральном репозитории. Команды сеанса, запросы и преобразования идут в упорядоченном обмене. Операции атомарны и спроектированы так, чтобы их можно было сделать идемпотентными. Это не утверждение об автоматической повторяемости каждой команды с любым расширением.

Связка HTTPS начинается с пустого POST. Соединение EoH установлено лишь после HTTP 200 с приветствием EPP и cookie сеанса. Успешный login затем открывает аутентифицированный сеанс EPP. Один последующий POST несёт одно сообщение, а ответ после обработки — один ответ EPP.

Порт 443 и знакомая облачная инфраструктура снижают эксплуатационные издержки. Они не превращают EPP в обычный stateless API. Проект называет отображение туннелированием и сознательно ограничивает привычные возможности HTTP: кэш, мультиплексирование, инфраструктурную аутентификацию, журналирование и автоматические повторы нельзя наследовать без учёта EPP.

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

Неопределённость нужно учитывать, а не переименовывать

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

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

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

Идемпотентность оценивают по полной команде

RFC 9110 не считает POST идемпотентным методом. Автоматический повтор неидемпотентного запроса оправдан, только если клиент знает о фактической идемпотентности семантики либо может установить, что первый запрос не применялся. Прокси не должен автоматически повторять такие запросы.

Редакция 04 вводит прикладной тест. Клиент EoH может повторить запрос, если сбой может быть временным, семантика HTTP-статуса допускает повтор и клиент знает, что вся команда EPP вместе с расширениями имеет идемпотентную прикладную семантику. Повтор должен содержать ту же команду и тот же clTRID, если он был. Следующая команда запрещена до действительного ответа или отказа от сеанса.

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

Промежуточному узлу обычно недоступно это знание. Балансировщик видит тайм-аут и backend, сервисная сеть — маршрут, библиотека — политику повторов. Они не владеют смыслом расширения и порядком команд. Поэтому проект требует отключить автоматический retry POST EPP в подконтрольных посредниках.

clTRID обеспечивает связь, но не обещает дедупликацию

RFC 5730 позволяет клиенту добавить clTRID; уникальность в собственном пространстве обеспечивает клиент. Серверный ответ объединяет его с уникальным svTRID, назначенным сервером. Пара поддерживает целостность синхронизации команды и ответа; идентификаторы рекомендуется журналировать, хранить и защищать.

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

Корреляция говорит, какие сообщения относятся к одному делу. Идемпотентность говорит, совпадает ли предполагаемый эффект повторных исполнений. Дедупликация говорит, предотвращает ли сервер дополнительное исполнение. Один идентификатор не отвечает автоматически на все три вопроса.

Ожидание сохраняет причинную цепочку

HTTP/2 и HTTP/3 поддерживают мультиплексирование. EoH всё равно запрещает более одного незавершённого HTTP-запроса на сеанс EPP. Если посредник создаёт параллелизм, сервер обязан определить, отклоняет он запросы или сериализует их.

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

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

Акт диспозиции команды

HTTP-журнал обычно строится вокруг маршрута, статуса, задержки, backend и числа попыток. Журнал EPP — вокруг XML, кода результата и транзакций. Объект управления должен соединить оба вида доказательств:

  1. тип команды, затронутый объект и канонический отпечаток полного сообщения с расширениями;
  2. сеанс EPP, clTRID и идентификатор каждой HTTP-попытки;
  3. время начала отправки и последнюю точку, где недоставку ещё можно доказать;
  4. наблюдение HTTP и компонент, фактически сформировавший ответ;
  5. код EPP и svTRID, если действительный ответ получен;
  6. трёхзначную диспозицию: подтверждённый успех, подтверждённый отказ, неопределённо;
  7. источник, версию и охват обоснования идемпотентности;
  8. доказательство барьера для последующих команд;
  9. лицо или политику, разрешившие повтор, отказ от сеанса либо сверку;
  10. доказательство закрытия, время, уверенность и остаточные расхождения.

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

The Policy Mirror раскрывает институциональный смысл настройки. Кто получает право повторить преобразование? Кто несёт ущерб, если первый запрос уже сработал? Кто видит доказательство и может его оспорить? Если посредник выигрывает красивый показатель доступности, а стоимость сверки уходит регистратору или владельцу, технический default уже распределяет власть и риск.

У проекта тоже есть точный статус

Редакция 04 — активный Internet-Draft рабочей группы REGEXT, предназначенный для Standards Track. Это не RFC; документ не завершил рассмотрение IESG и истекает 7 марта 2027 года. Сентябрьский ориентир подачи на публикацию — план, а не доказательство состоявшегося решения.

Раздел реализации называет Verisign EPP SDK и работу IIT-CNR/Registro.it. Предупреждение по RFC 7942 говорит, что данные получены от участников, не проверены IETF, не означают одобрения и не являются каталогом. Это свидетельство заявленного опыта, но не всеобщего производственного соответствия.

Запись в реестре расширений IANA также предложена самим проектом. Предлагаемый текст не равен уже созданной активной записи. Точность в описании статуса нормы — часть той же дисциплины, что отделяет HTTP 200 от решения EPP.

Источники

  1. IETF — EPP Transport over HTTPS, редакция 04
  2. IETF Datatracker — статус документа
  3. IETF Datatracker — история
  4. Рабочая группа REGEXT
  5. RFC 5730 — Extensible Provisioning Protocol
  6. RFC 5731 — EPP Domain Name Mapping
  7. RFC 5734 — EPP Transport over TCP
  8. RFC 9110 — HTTP Semantics
  9. RFC 7942 — Improving Awareness of Running Code
  10. IANA — Extensions for EPP
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  12. Lu Heng — The Policy Mirror