Кратко

  • draft-ietf-regext-epp-https-04 датирован 3 сентября 2026 года и остаётся рабочим Internet-Draft группы REGEXT. Это не RFC, не одобрение IETF и не доказательство внедрения.
  • Если запрос дошёл до обработки EPP и сформирован ответ EPP, внешняя оболочка возвращает HTTP 200 (OK) и при успехе, и при отказе команды. Эти коды описывают разные результаты.
  • Если обработка могла состояться, но действительный ответ EPP не пришёл, исход неопределён. Посредники не должны повторять POST; решение остаётся за EoH-клиентом, который знает семантику всей команды, сохраняет идентификатор и порядок.

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

draft-ietf-regext-epp-https-04 переносит протокол EPP с состоянием на HTTPS. RFC 5730 требует сохранять порядок команд, сессию и соответствие ответа запросу. Новый транспорт не делает EPP REST-интерфейсом. Он проводит прежний XML-диалог через POST, позволяя использовать WAF, балансировщики и мониторинг прикладного уровня.

Соединение начинается с пустого POST на URL, сообщённый вне протокола. Корректный ответ содержит приветствие EPP, application/epp+xml, no-store, nosniff и cookie сессии. Лишь успешный EPP <login> создаёт аутентифицированную сессию.

Код 200 относится к доставке оболочки

После входа каждый POST несёт одну команду, а каждый HTTP-ответ — один ответ EPP. Когда запрос обработан слоем EPP и ответ создан, внешний статус равен 200 независимо от успеха или ошибки внутри.

4xx и 5xx описывают проблемы HTTP: неверный формат, неподдерживаемый тип, ограничение размера или частоты, перегрузку, ошибку шлюза. Клиент не получил авторитетного ответа EPP. Однако один внешний код не всегда доказывает, что состояние реестра осталось прежним.

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

Нужно связывать как минимум HTTP-статус, результат EPP и клиентский идентификатор транзакции. Первый показывает путь через веб-слой, второй — решение реестра, третий — что попытка восстановления относится к исходному намерению.

Потерянный ответ не отменяет выполненную команду

Самый опасный случай возникает после возможного исполнения. Клиент отправляет команду изменения, реестр её обрабатывает, но обратный ответ пропадает из-за сбоя соединения или переключения backend. У клиента нет ни успеха, ни отказа EPP. Проект называет исход неопределённым.

Автоматический повтор может превратить восстановление во второе действие. POST не является идемпотентным по определению HTTP. Команды EPP спроектированы так, чтобы их можно было сделать идемпотентными, но безопасность зависит от конкретной команды и всех расширений. Универсальный прокси этого смысла не знает.

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

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

Параллельный HTTP не означает параллельный EPP

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

Cookie обозначает логическое EPP-соединение даже при разных HTTP-соединениях. В кластере можно закрепить сессию за экземпляром или хранить состояние совместно. Привязка проще, но без репликации теряет активные сессии при отказе экземпляра. Общий storage облегчает failover, однако сам входит в границу безопасности и доступности.

Запросы одного соединения должны обрабатываться последовательно, изменения состояния — атомарно, а сроки жизни HTTP-, EPP-сессии и сохранённого состояния — совпадать. Иначе HTTPS endpoint остаётся зелёным, хотя разговор с реестром уже исчез.

Проект упоминает разрабатываемый Verisign SDK для HTTP/1.1 и HTTP/2 и немного иную схему Registro.it, работающую с 2009 года. Сам документ подчёркивает: сведения даны участниками и не проверялись IETF. Это свидетельство эксперимента, но не распространённости, соответствия или качества.

Разделение слоёв реальности у Heng Lu здесь прикладное: доставка HTTP, решение EPP, состояние реестра, публикация DNS и наблюдение пользователя — отдельные факты. Приоритет работающего кода отдаёт восстановление тому компоненту, который понимает команду, удерживает порядок, хранит идентификатор и может сверить авторитетное состояние.

HTTPS обновляет транспорт. Он не объединяет два результата в одну истину.

Источники