Resumo

  • A coleção filtrada Complete é opcional e inclui tanto tarefas bem-sucedidas quanto solicitações processed que não terão novas atualizações. A classificação não equivale a sucesso geral.
  • O estado individual complete exige êxito nas ações pertinentes, inclusive nas CDNs seguintes que forem afetadas. Um intermediário não pode transformar processed de uma descendente em sucesso confirmado.
  • A previsão de término ajuda no planejamento, mas não comprova execução. Essa interface não exige sincronizar os relógios das CDNs interligadas.
  • Invalidar, purgar, adquirir antecipadamente, cancelar e apagar um informe têm efeitos diferentes. A decisão seguinte deve identificar qual resultado realmente precisa.
  • O cenário de substituição abaixo é uma análise da especificação, não um incidente observado nem uma medição da adoção comercial.

Quando a fila fica limpa cedo demais

Um responsável por conteúdo pretende substituir material nas mesmas URLs. Primeiro pede ao parceiro de distribuição que purgue a versão anterior. Só depois quer que o conteúdo novo seja adquirido antecipadamente. A ordem tem um motivo concreto: evitar que a purga antiga alcance o material recém-carregado.

O parceiro aceita a solicitação. Mais tarde, o recurso de estado aparece na coleção Complete. O painel deixa de mostrar aquela solicitação entre as atividades que ainda acompanha. Parece uma boa oportunidade para liberar a próxima etapa.

O estado individual, porém, pode ser processed. A solicitação foi aceita, mas não haverá novas atualizações; esse estado também serve quando não é possível confirmar a conclusão. O painel encerrou uma pergunta sobre acompanhamento. O responsável pela substituição ainda tem uma pergunta sobre efeito.

Esse exemplo é hipotético. RFC 8007 permite uma resposta honesta com capacidade limitada de acompanhamento. O risco analisado surge quando outro participante toma essa limitação como uma garantia mais forte, necessária para seu próprio trabalho.

Não se está dizendo que uma CDN específica implementou esse erro. Tampouco que todas as redes usam a interface. A questão é o limite de uma decisão que pode ser extraída de significados documentados.

Uma coleção reúne dois tipos de encerramento

Publicado em dezembro de 2016, RFC 8007 é um documento Standards Track da IETF; a ficha do RFC Editor o apresenta como Proposed Standard. Define a parte de acionamento da interface de controle CDNI.

Uma CDN solicitante pede trabalho a outra que distribui conteúdo em seu nome. Pode solicitar aquisição, invalidação ou purga de metadados e conteúdo, além de consultar o estado da atividade. Isso não uniformiza toda a relação comercial, a configuração inicial ou cada mecanismo local de autorização.

A rede receptora mantém uma coleção de recursos de estado para cada solicitante. Pode oferecer coleções filtradas e, quando as implementa, deve fornecer os respectivos links na coleção geral. Essas vistas não são uma obrigação universal de toda implementação.

Complete reúne tarefas concluídas com sucesso e solicitações processed para as quais não serão publicados novos estados. O nome organiza o acompanhamento. Não acrescenta a cada item uma promessa de êxito que seu estado individual não contém.

O estado individual complete significa conclusão bem-sucedida. Processed significa aceitação sem futuras atualizações, inclusive quando a conclusão não pode ser confirmada. A diferença sobrevive ao fato de ambos aparecerem na mesma coleção.

Processed não é sempre fracasso. Também não é sempre sucesso, ausência de execução, trabalho interrompido ou ausência de efeitos futuros. A informação afirma um limite de relato, não todas as propriedades do trabalho subjacente.

Assim, quem decide quais informes ainda acompanhar pode terminar sua tarefa antes de quem precisa comprovar um resultado para agir. Uma fila organizada é útil, mas não responde sozinha à dependência da operação seguinte.

O recebimento fornece um lugar para consultar

Ao aceitar um acionamento, a CDN receptora cria um recurso de estado e retorna sua localização com HTTP 201. O solicitante ganha uma referência para verificar a sequência. A resposta não demonstra que todas as ações pedidas já ocorreram.

A referência deve ser a que foi devolvida pelo serviço. O solicitante não pode presumir a estrutura das URLs nem transformar exemplos em um formato obrigatório. Uma URI de recurso de estado nunca deve ser reutilizada depois da remoção, para que uma referência antiga não passe a identificar silenciosamente outra tarefa.

Uma implementação capaz de acompanhar o progresso pode informar espera, atividade e, por fim, êxito ou falha. Se não puder fornecer esse acompanhamento, deve revelar a limitação com processed e inserir o recurso em Complete. Também deveria apresentar uma previsão de término adequada ao planejamento.

Há casos legítimos sem atividade nova. A purga pode visar dados que a rede ainda não adquiriu. A aquisição antecipada pode visar dados já presentes e válidos. A especificação permite processed ou complete nesses casos.

Por isso, um resultado bem-sucedido não mede automaticamente bytes transferidos ou dispositivos esvaziados. É preciso considerar o pedido, seu alcance e o resultado que ele significa. Contar itens encerrados não substitui essa interpretação.

A cadeia não pode melhorar uma confirmação ausente

Uma CDN receptora pode passar a distribuição para outras redes. Os comandos devem seguir para as descendentes que possam ser afetadas. A conclusão da parte local de um intermediário não resolve o que acontece nessas outras redes.

RFC 8007 não permite informar complete antes que o comando seja complete em todas as CDNs descendentes pertinentes. Se uma descendente informa processed, os intermediários também devem informar processed, sem elevar a resposta a sucesso.

Isso não exige um centro escolhendo cada passo de execução. Exige que o significado agregado continue compatível com a evidência obtida. A distribuição da decisão não autoriza uma multiplicação fictícia da certeza.

Uma falha pode ser informada assim que surge em uma rede ou em uma descendente. A lista de erros identifica URLs ou padrões solicitados. Algumas partes podem já apresentar problemas enquanto a solicitação continua ativa para outras.

As referências incluídas nos erros devem permanecer exatamente como no pedido, sem serem generalizadas para um alcance maior. Uma parte que falhou não prova falha universal; outra ainda sem erro comunicado não ganha, por isso, prova de sucesso.

Essa granularidade permite continuação seletiva. Uma tarefa independente pode ter resultado suficiente, enquanto outra depende de uma confirmação que ainda falta. Paralisar tudo e aprovar tudo são respostas que podem ignorar a dependência real.

Os requisitos CDNI de RFC 7337, documento Informational, já pediam informação adequada sobre conclusão, êxito ou falha, inclusive em cascatas. O acionamento oferece uma forma concreta de preservar também a capacidade limitada de acompanhamento.

O êxito depende do tipo de trabalho

A aquisição antecipada solicita metadados ou conteúdo. A invalidação exige revalidar os dados antes de usá-los novamente, sem exigir apagá-los. A purga requer que os dados especificados deixem de ser mantidos após o atendimento, embora possam ser adquiridos de novo quando necessários.

O registro atual da IANA conserva essa distinção. Uma restrição sobre reutilização não é o mesmo efeito físico que retirar dados do armazenamento.

A especificação permite complete para invalidação com servidores de cache afetados fora de serviço, desde que eles não reutilizem os dados sem revalidação quando voltarem. O resultado garante uma condição de uso futuro, não que cada equipamento desconectado já foi esvaziado.

Purga e aquisição antecipada podem ser processed quando o trabalho será concluído após a volta dos servidores de cache. Se o trabalho for abandonado, deveria ser informado um erro. Não há equivalência entre toda classificação terminal e apagamento já comprovado.

O alcance continua sendo os dados e a distribuição pedidos. Nenhum desses informes prova desaparecimento de toda cópia na internet. Uma alteração posterior de estado também não recolhe material já entregue ao destinatário.

Pedir na sequência não controla a sequência remota

O início e o ritmo da atividade ficam sob controle da CDN receptora. Purga e invalidação devem abranger dados adquiridos antes da aceitação. Não deveriam alcançar aquisições posteriores, mas o solicitante não pode contar com uma exclusão sempre realizável.

O tratamento de uma aquisição já iniciada quando chega o comando também depende da implementação. Duas solicitações enviadas em ordem não estabelecem um corte global preciso entre material antigo e novo.

Por isso, RFC 8007 recomenda concluir purga ou invalidação antes de iniciar a aquisição antecipada do substituto nas mesmas URLs. Se os trabalhos se sobrepõem, o material novo pode ser adquirido e logo afetado pelo comando anterior ainda em execução.

Uma configuração em diamante pode acrescentar comandos repetidos por caminhos legítimos diferentes. A rede receptora pode programá-los separadamente. Uma purga termina em uma ramificação, que então pede aquisição, enquanto outra purga ainda alcança o conteúdo recém-adquirido.

Reaquisição pode recuperar disponibilidade. Não significa que a primeira liberação de trabalho tinha uma prova instantânea de que toda operação concorrente havia terminado.

O responsável pela substituição deve identificar sua condição prévia. Precisa de êxito confirmado para determinado alcance? Aceita uma previsão e a incerteza correspondente num acordo local? A próxima tarefa é independente da parte incerta? A coleção Complete não escolhe nenhuma dessas alternativas por ele.

Uma previsão não vira atestado ao vencer

A propriedade opcional etime informa quando a CDN espera concluir a atividade. Ajuda a planejar o carregamento seguinte. Não atesta que a tarefa teve êxito quando aquele instante chega.

Os tempos de criação, modificação e término previsto são determinados pela rede que informa. A interface não exige sincronizar os relógios das CDNs interconectadas. Ordenar números de operadores diferentes não basta para reconstruir causalidade.

Um acordo local pode considerar bases de tempo e incertezas. Esse acordo não muda a definição de processed. Mesmo com relógios bem alinhados, a previsão continua sendo uma expectativa, não um resultado recebido.

Solicitações HTTP condicionais reduzem o custo de observar. RFC 8007 recomenda ETags para recursos e coleções. A semântica HTTP e as regras de cache explicam esses instrumentos.

Uma resposta 304 a um recurso processed sem mudança confirma que a representação permaneceu igual. Não preenche a confirmação que deixou de ser prometida. Aumentar a frequência de consulta não amplia a capacidade de informar do parceiro.

Cancelamento não restaura o passado

O serviço deve responder adequadamente ao comando de cancelamento, mas realizar de fato o cancelamento é opcional. Pode indicar trabalho inativo, aceitação enquanto a atividade continua ou ausência de implementação.

Uma tarefa pendente pode começar antes do processamento do cancelamento. Uma ativa pode não parar imediatamente. Não há uma reversão geral das ações já realizadas. Uma tarefa complete ou failed não deve ser reclassificada retroativamente como cancelada.

Os valores do protocolo também precisam de atenção. A errata técnica verificada 5053 corrige as cadeias para cancelling e cancelled; 5054 corrige ecancelled. A errata editorial 5064 explicita um exemplo de cancelamento distinto de apagar o recurso. A explicação em português não pode trocar a grafia desses valores.

Apagar o recurso retira o lugar de consulta e suas referências nas coleções. O efeito lembra cancelamento, mas não mantém o informe posterior. Um GET que falha depois da remoção não revela qual resultado havia ocorrido antes dela.

A retenção automática também delimita a observação. Se recursos antigos forem removidos, a duração correspondente precisa ser anunciada. Mantê-los por pelo menos vinte e quatro horas é uma recomendação, não um mínimo obrigatório sem exceções. O solicitante deveria recolher o resultado necessário antes de sua janela fechar.

Um canal protegido pode transmitir um limite honesto

As ações devem ficar restritas aos dados do solicitante correspondente. O caso em diamante reconhece possíveis caminhos legítimos de aquisição, não uma autoridade geral para interferir em dados alheios.

As coleções são próprias do solicitante e não devem ser expostas a outras CDNs. TLS e autenticação remota são exigidos salvo proteção alternativa adequada. O controle concreto de acesso é local, e a confiança comercial fica fora da definição do protocolo.

As recomendações atuais de TLS substituem as orientações anteriores citadas originalmente. Um canal protegido ajuda a estabelecer a procedência do informe. Não garante que cada ação solicitada terminou com êxito.

O modelo CDNI, os metadados e os registros fornecem evidências complementares. Uma entrega saudável ou um registro correto em um ponto não comprova o estado de todo equipamento desconectado ou descendente.

Fontes

Os documentos primários fundamentam as diferenças de significado. As propostas de decisão são análise do autor, não novos requisitos.