Resumo

  • 201 Created prova a criação de um recurso de trigger no CDN que recebeu o pedido. Não prova que purge, invalidate ou preposition terminou.
  • Depois de aceitar a solicitação, um CDN de trânsito deve converter a rejeição HTTP síncrona de outro CDN em Error.v2 assíncrono no próprio recurso de estado. Informar o PID de quem recusou é opcional.
  • Cancelamento, exclusão do registro, contadores acumulados, reconciliação de nós e resultado para o usuário são controles diferentes.

O recibo pertence à fila, não ao conteúdo

Um CDN A solicita a B que apague determinado conteúdo. B valida o pedido, cria um recurso de trigger e devolve 201 Created. Em seguida, B repassa o trigger a C. C não reconhece uma parte da solicitação e responde 400 Bad Request.

O recibo de B é verdadeiro: há um recurso em B. Mas ele não é recibo da retirada do conteúdo em C. A diferença parece óbvia quando escrita em duas linhas; costuma desaparecer quando o painel resume toda a cadeia numa única cor.

A revisão 20 do CDNI Control Interface / Triggers 2nd Edition, de 2 de setembro de 2026, preserva essa diferença. O Datatracker mostra um Internet-Draft ativo do grupo CDNI, em estado WG Document. O texto substituiria a RFC 8007 se aprovado. Ainda não é RFC, decisão da IESG, relatório de implementação ou evidência sobre qualquer fornecedor real.

Em relação à revisão 19, a nova versão detalha tratamento e propagação de erros. A notícia não é a existência de purge; é a obrigação de representar uma recusa tardia depois que outra fronteira já aceitou o pedido.

A falha atravessa uma mudança de forma

Se B percebe antes da criação que o pedido é malformado, não autorizado ou usa algo que B não suporta, responde 4xx e não cria o recurso. Se B já aceitou, a transação HTTP com A terminou. O 4xx ou 5xx posterior de C não pode substituir a resposta antiga.

B precisa então transformar a recusa em Error.v2 Description e incluí-la no array de erros do seu recurso. Falhas assíncronas comunicadas por C também sobem por esse caminho. A descobre o problema numa consulta posterior, por exemplo com estado failed e código eunsupported.

Em C, a evidência era uma resposta direta. Em A, é um relato posterior feito por B. Guardar só o 201 perde a falha; guardar só o erro final perde quem fez a tradução e em qual ordem.

O PID do CDN em que o erro surgiu pode acompanhar o Error.v2, mas não é obrigatório. B pode usar o próprio PID e ocultar C. Os registros de parâmetros CDNI da IANA tornam os códigos compartilháveis; não obrigam a revelar toda a cadeia operacional.

Complete e processed não são vizinhos intercambiáveis

O estado normal passa de pending a active e termina em complete ou failed. Um CDN de trânsito não pode dizer complete até que ele e todos os descendentes tenham concluído. Se qualquer parte disser processed, o trânsito também precisa dizer processed.

Processed significa que o pedido foi aceito, mas não haverá novas atualizações de estado. É uma declaração de limite observacional, não uma forma discreta de sucesso. O identificador único recomendado com base na RFC 9562 mantém a identidade do recurso e evita reutilização de URI; não autentica a tarefa.

Se uma ramificação falhar, o trânsito só reporta failed depois de encerrado o processamento local e em todos os descendentes. O terminal descreve o fechamento do grafo conhecido. Não marca automaticamente o primeiro erro nem a correção vista pelo público.

Somar sem deduplicar é parte da regra

A versão 20 acrescenta indicadores acumulados de objetos, nós e bytes afetados. Recomenda somar todos os nós e CDNs em cascata sem deduplicar o mesmo objeto tratado em locais diferentes. O objetivo é detectar um volume inesperado.

Logo, dez mil ocorrências não provam dez mil objetos únicos. Zero também não prova falha: purge ou invalidate sem correspondência conhecida pode terminar com sucesso. O contador precisa viajar com sua definição, o escopo esperado e uma medição independente no caminho do usuário.

Cancelar pode chegar depois do trabalho

Implementar a interrupção efetiva é opcional. B pode aceitar o cancelamento quando o trigger que A viu como pending já ficou active. Processamento active ou processed pode terminar antes da parada. Cancelling informa uma transição em andamento, não que os efeitos cessaram.

Excluir o recurso remove o histórico de estado e faz consultas futuras receberem 404 Not Found. Por isso o rascunho recomenda cancelar, em vez de excluir, quando A ainda precisa examinar o terminal. 204 No Content diz que o recurso de acompanhamento foi removido; não desfaz a atividade.

O próprio conjunto de dados tem fronteira temporal. Purge e invalidate devem atingir dados adquiridos antes do início de active e deveriam cobrir aquisições já em curso. Dados adquiridos depois não deveriam ser atingidos, mas o CDN a montante não deve depender de essa separação ser sempre possível. Sem ordem explícita, um preposition de substituição pode ser apagado pela purga anterior.

A linhagem técnica começa no problema de interconexão da RFC 6707, passa pelo framework da RFC 7336 e pelos requisitos da RFC 7337. A RFC 9110 define os métodos e status HTTP. Nada nessa composição autoriza um status de criação a falar pelo resultado de toda a cadeia.

Um nó ausente ainda volta

A indisponibilidade temporária de um nó do dCDN deve ser tratada internamente e, sozinha, não deveria alterar o estado publicado. Antes de voltar ao serviço normal, o nó precisa ser reconciliado com os triggers executados durante sua ausência.

Isso simplifica a interface, mas transfere confiança ao operador. O terminal que A viu não foi uma observação direta daquele nó. Um teste após o retorno mede um risco distinto: a reintrodução de estado antigo.

Topologias em diamante podem entregar metadados conflitantes por caminhos e atrasos diferentes, sendo tratadas como erro de configuração. Caminhos de PID ajudam a detectar loops, mas não garantem que A enxergue todos os participantes.

O protocolo constrói um relato melhor. Não transforma o relato na totalidade do serviço.