Resumo

  • Datado de 3 de setembro de 2026, draft-ietf-regext-epp-https-04 é um Internet-Draft ativo do grupo REGEXT. Não é RFC, aprovação da IETF nem prova de adoção.
  • Se a requisição chega ao processamento EPP e gera uma resposta EPP, o servidor devolve HTTP 200 (OK) tanto para sucesso quanto para falha do comando. Os dois códigos pertencem a camadas distintas.
  • Se o processamento pode ter ocorrido, mas nenhuma resposta EPP válida chega ao cliente, o resultado é indeterminado. Intermediários não podem repetir o POST automaticamente; só o cliente que conhece a semântica completa pode decidir, preservando idempotência, identificador e ordem.

Um painel pode mostrar cem respostas HTTP bem-sucedidas e esconder cem recusas do registro. O problema não é o número estar errado. É a legenda prometer mais do que ele observou.

draft-ietf-regext-epp-https-04 mapeia para HTTPS o protocolo XML com estado usado no provisionamento de objetos em repositórios compartilhados. RFC 5730 exige ordem de comandos, sessão persistente e resposta coordenada. O rascunho não transforma EPP em REST. Ele transporta a conversa existente em POSTs, permitindo reaproveitar firewall, balanceador e observabilidade de aplicações web.

A conexão EoH começa com um POST vazio para uma URL fornecida fora do protocolo. A abertura válida entrega greeting EPP, application/epp+xml, no-store, nosniff e um cookie. Um <login> EPP bem-sucedido cria então a sessão autenticada.

Sucesso de transporte não é aceite do registro

Depois do login, um POST transporta um comando e a resposta HTTP transporta uma resposta EPP. Se a camada EPP recebeu a requisição e produziu uma resposta, o status externo é 200, mesmo quando o código interno informa falha.

Estados 4xx e 5xx pertencem a problemas HTTP: mensagem malformada, mídia incompatível, tamanho excessivo, limite de taxa, sobrecarga ou gateway. Eles indicam que o cliente não recebeu uma resposta EPP autoritativa. Não informam, sozinhos, o estado final do objeto.

Uma sessão inválida mostra bem a separação. Se a requisição sem cookie válido alcança o processador EPP, o servidor devolve o erro EPP 2002 dentro de HTTP 200. Chamar todo 200 de operação registral bem-sucedida transforma uma recusa explícita em indicador verde.

O registro de auditoria precisa unir status HTTP, resultado EPP e identificador de transação do cliente. O primeiro localiza a requisição no caminho web. O segundo contém a decisão registral. O terceiro prova que uma eventual recuperação continua ligada à intenção original.

A resposta perdida cria uma terceira situação

Uma falha explícita é mais simples do que silêncio. O cliente recebe o código EPP e sabe que a transformação não foi aceita. Mas o registro pode executar o comando antes que uma interrupção apague a resposta. Nesse caso, o cliente não sabe se deve considerar a mudança feita. O rascunho chama o resultado de indeterminado.

Repetição automática pode duplicar a decisão. POST não é idempotente por definição HTTP. Os comandos EPP foram desenhados para poderem ser idempotentes, mas a segurança depende do comando concreto e de todas as extensões. Um proxy genérico não conhece essa semântica.

A revisão 04 limita a repetição ao cliente EoH. Ele precisa saber que a falha pode ser transitória, que o status HTTP permite a tentativa e que o comando completo é idempotente. A nova mensagem mantém comando e identificador de transação. Nenhum comando posterior pode avançar até chegar uma resposta válida ou a sessão ser abandonada. Intermediários sob controle do operador devem ter a repetição automática de EPP POST desabilitada.

Isso preserva causalidade. Um identificador novo faz a mesma intenção parecer outra ordem. Um comando posterior pode operar sobre estado desconhecido. Uma repetição no gateway desloca a autoridade de quem entende EPP para quem só observou timeout.

Multiplexação não muda a ordem do registro

HTTP/2 e HTTP/3 podem multiplexar requisições, mas EoH proíbe mais de uma requisição pendente na mesma sessão EPP. Como um intermediário ainda pode criar concorrência, o servidor deve definir se rejeita ou serializa.

O cookie identifica a conexão lógica mesmo quando as mensagens passam por conexões HTTP diferentes. Num conjunto de instâncias, a sessão pode ficar presa a um backend ou residir em um armazenamento compartilhado. Afinidade é simples, mas perde sessões quando a instância cai, salvo replicação. Estado compartilhado facilita manutenção e failover, mas vira parte do limite de segurança e disponibilidade.

As requisições da mesma conexão precisam ser processadas em sequência e as mudanças no estado devem ser atômicas. A vida do armazenamento deve acompanhar as sessões HTTP e EPP. Caso contrário, o endpoint continua respondendo enquanto a conversa registral que ele representa já morreu.

O rascunho relata um SDK Verisign em desenvolvimento para HTTP/1.1 e HTTP/2 e uma variante usada pela Registro.it desde 2009. O próprio texto avisa que essas informações vieram dos contribuidores e não foram verificadas pela IETF. São sinais de código em execução, não auditoria de conformidade, desempenho ou adoção.

A disciplina de separar camadas de realidade de Heng Lu impede o atalho: entrega HTTP, decisão EPP, estado armazenado, publicação DNS e observação do usuário não são equivalentes. A primazia do código em execução indica o controlador legítimo da recuperação: o componente que entende o comando, bloqueia a sequência, preserva o identificador e consulta o estado autoritativo.

HTTPS pode modernizar o caminho. Não reduz duas decisões a uma luz verde.

Fontes