Resumo

  • Bindings WebDAV fazem URIs diferentes alcançar o mesmo recurso. Quando o destino é uma coleção, outro binding expõe os mesmos membros sob novo prefixo e pode criar um ciclo.
  • Em um PROPFIND Depth: infinity de cliente consciente de bindings, uma ocorrência recebe 200 e tem os descendentes enumerados. Os caminhos seguintes permanecem como respostas 208 Already Reported, sem repetir o subgrafo.
  • DAV:resource-id prova a identidade estável por baixo dos caminhos. O cliente preserva cada aresta e expande cada coleção uma vez; sem entendimento negociado de 208, um loop deve produzir 508, não uma omissão silenciosa.

O arquivo possuía duas entradas para uma sala

Uma sala de documentos pode ser alcançada por duas portas, cada uma pertencente a um corredor. As duas portas são fatos do prédio. A sala e seus armários, porém, não se duplicam.

Um inventário orientado apenas por caminho entra por cada porta e conta tudo novamente. Se um corredor volta a um andar anterior, a caminhada pode criar nomes infinitos dentro de uma construção finita. Um inventário orientado apenas por objeto evita o ciclo apagando a segunda porta.

208 escolheu não falsificar nenhum dos lados. Registra a porta posterior, comprova que ela leva à coleção já aberta e encerra somente a descida repetida.

É uma deduplicação de trabalho, não de relações.

Multi-Status já separava envelope e evidência

O RFC 4918, de 2007, descreve o estado de uma coleção WebDAV como mappings entre segmentos de caminho e recursos, além das propriedades da coleção. Um nome de membro é uma relação de acesso, não o recurso em si.

PROPFIND usa Depth 0, 1 ou infinity. A profundidade infinita alcança todos os descendentes. O resultado vem num 207 Multi-Status, cujo corpo contém uma lista plana de DAV:response; cada href identifica um caminho e cada propstat contém estados de propriedades.

O 207 externo nunca dispensou a leitura dos resultados internos. Ele é o envelope de uma conta plural. Essa arquitetura abriu espaço para 208 qualificar uma ocorrência específica sem declarar que a solicitação inteira já havia sido respondida.

O WebDAV básico admitia múltiplas URIs para um recurso. A extensão de binding deu ao cliente um método para criar essa segunda rota de modo explícito.

BIND acrescentava relação, não recurso

O RFC 5842, publicado como Experimental em abril de 2010, define BIND, UNBIND e REBIND. BIND associa um segmento dentro de uma coleção a um recurso existente, criando uma URI utilizável para chegar ao mesmo alvo.

O binding é novo; o objeto não. Duas coleções podem possuir relações distintas para o mesmo recurso.

A integridade do binding exige que ele continue existindo e apontando para a mesma identidade até uma operação explicitamente removê-lo ou alterá-lo. Remover uma aresta não pode transformar outra em caminho quebrado nem permitir a recuperação do recurso enquanto uma ligação permanece.

Um alias não é uma cópia, mas também não é decoração descartável. É estado independente da coleção que o contém.

Um binding de coleção projetava os filhos

Se o destino for um recurso folha, o novo binding acrescenta outro mapping. Se for coleção, seus membros passam a ser acessíveis sob o novo prefixo sem que cada binding interno seja copiado.

Assim, uma quantidade finita de recursos pode produzir muitos caminhos. Ligar uma coleção a si mesma ou a um ancestral gera sequências de URI cada vez mais longas que voltam ao mesmo nó.

RFC 5842 obriga a detecção de loops durante Depth: infinity. O servidor pode recusar a criação do ciclo, pois o suporte a loops é opcional. Aceitá-los significa reconhecer que a travessia é de grafo.

O perigo infinito não está nos dados armazenados, mas no algoritmo que trata cada URI como objeto novo.

resource-id mantinha a identidade sob as rotas

Caminhos diferentes não provam recursos diferentes. Conteúdo igual também não prova um único recurso, porque objetos independentes podem coincidir agora e divergir depois.

RFC 5842 torna DAV:resource-id obrigatório. Ele nasce com o recurso, é único entre todos os recursos para sempre, não muda quando o recurso existente é atualizado ou movido por REBIND e não pode ser reutilizado mesmo depois de perder todas as URIs.

Valores idênticos caractere por caractere, obtidos por bindings distintos, provam que as rotas chegam ao mesmo objeto. O ID não promove uma URI preferencial. É a identidade que sobrevive às mudanças de endereço.

Solicitá-lo no PROPFIND permite reconstruir o grafo e justificar por que uma subárvore não aparece novamente.

Dois livros-caixa evitavam dois erros

O primeiro livro registra cada binding: pai, segmento, href e destino. O segundo registra quais identidades de coleção já tiveram os descendentes expandidos nesta resposta.

Usar apenas o primeiro preserva a topologia, mas repete trabalho e segue ciclos. Usar apenas o segundo interrompe a recursão, mas pode apagar uma aresta real antes de registrá-la.

A ordem correta é registrar a relação e só depois consultar o estado de expansão do nó. O recurso pode ser compartilhado sem que os caminhos sejam fundidos.

208 conecta os dois livros: esta rota existe; a coleção por trás dela já forneceu seu conjunto de descendentes em outra ocorrência.

O alias posterior continuava visível

A regra de 208 é específica. Ele pode aparecer dentro de DAV:propstat para Depth: infinity. Entre bindings para uma coleção no escopo, uma ocorrência recebe 200; as posteriores têm seus próprios elementos DAV:response com 208 e não repetem respostas para descendentes.

O segundo href não desaparece. DAV:resource-id o relaciona ao primeiro caminho.

No exemplo do RFC, /Coll/ e /Coll/Bar têm o mesmo ID. O primeiro recebe 200 e expande membros. O segundo recebe 208. Não se prossegue por /Coll/Bar/Bar, pois isso apenas retorna ao mesmo nó.

Already Reported descreve o histórico de expansão do Multi-Status atual. Não declara que o alias é inválido ou dispensável.

O primeiro 200 não virava endereço soberano

Uma ocorrência precisa carregar a expansão para tornar a resposta finita. A escolha não transforma esse caminho em original, canonical ou dono das demais relações.

Bindings distintos continuam pertencendo ao estado de suas coleções e podem representar contextos diferentes de navegação, autorização e auditoria. Apagar os caminhos 208 esconde esses contextos.

Uma implementação pode então confundir UNBIND com destruição do objeto, ou permitir que o pai da rota escolhida fale por todas as outras coleções.

Quem percorreu primeiro não ganha poder sobre todas as entradas.

207 permanecia como envelope externo

Na linha de estado da solicitação aparece normalmente 207 Multi-Status. O 208 vive no detalhamento de uma ocorrência no corpo.

Logo, ele não diz que o cliente repetiu a solicitação HTTP nem que a resposta inteira já foi enviada antes. Diz que os descendentes daquela coleção foram relatados, neste mesmo documento, por outro binding.

href preserva a rota; resource-id une os caminhos ao mesmo nó; 200 e 208 indicam onde ocorreu a expansão.

Um intermediário que reduz tudo a sucesso verdadeiro carrega o envelope e elimina o conteúdo institucional do grafo.

A omissão era uma capacidade negociada

Descendentes ausentes podem estar já informados ou simplesmente perdidos. Um cliente antigo não distingue as hipóteses se desconhece 208.

O servidor anuncia a classe bind no cabeçalho DAV da resposta OPTIONS. O cliente deveria enviar DAV: bind e, ao fazê-lo, precisa compreender 208.

Por compatibilidade, o servidor não deveria usar 208 em Multi-Status sem esse sinal. Caso contrário, o receptor pode considerar o status desconhecido um erro ou concluir que a coleção não tem filhos.

Suprimir repetição não é uma otimização unilateral. É um contrato de interpretação que depende de identidade compartilhada e capacidade declarada.

508 encerrava o que 208 permitia continuar

Se um cliente sem consciência de binding encontra loop em PROPFIND profundo, RFC 5842 orienta 508 Loop Detected. Antes do streaming, pode ser top-level; durante um Multi-Status já iniciado, a falha pode aparecer no detalhamento.

Com 208, o cliente preparado continua: guarda o alias e omite a repetição. Com 508, o servidor termina porque encontrou loop infinito e a operação falha.

Não são versões branda e dura da mesma resposta. Uma é referência compreendida; a outra é limite explícito quando a referência não pode ser interpretada.

Falhar claramente preserva mais verdade do que entregar uma árvore aparentemente completa com lacunas invisíveis.

Mais caminhos também traziam mais risco

BIND cria nova via para loops acidentais ou hostis. A detecção profunda é obrigatória, mas não resolve toda exaustão.

RFC 5842 aponta riscos de privacidade e negação de serviço. Bindings entre servidores podem direcionar tráfego a destinos não preparados. DAV:parent-set, opcional, pode revelar locais privados e exigir listas manipuláveis por outros domínios administrativos.

208 contém a repetição numa resposta. Não define teto de CPU, memória, nós ou tamanho, nem decide quem pode criar binding. Um grafo finito ainda pode ser enorme.

O código preserva uma camada comum estreita: resolve a amplificação que consegue identificar, sem alegar resolver toda governança do namespace.

Mesmo objeto não significava toda propriedade igual

O resource-id comum comprova identidade, mas não torna toda observação independente de caminho. Dead properties não dependem da quantidade de bindings ou da rota; live properties seguem definições próprias e podem carregar contexto de caminho.

Fundir toda propriedade por ID apaga contexto. Tratar cada diferença como objeto separado apaga a identidade.

O modelo precisa distinguir fatos do recurso, fatos do binding e observações ligadas à rota. 208 usa a identidade apenas para evitar uma segunda expansão, não para anexar as demais camadas.

Coordenação é segura quando o poder de uma prova não excede aquilo que ela realmente demonstra.

IANA registrou um significado estreito

O registro IANA de códigos de status HTTP associa 208 Already Reported ao RFC 5842. O mesmo documento Experimental define 508, enquanto 207 aponta para o RFC 4918.

O registro não transforma a extensão em Internet Standard, não mede adoção atual e não faz de 208 um código genérico para duplicatas de banco, idempotência ou cache.

Seu contexto é preciso: WebDAV consciente de bindings, Depth infinity e Multi-Status compreendido pelo cliente.

A disciplina do escopo impede que a palavra “already” vire licença para apagar qualquer repetição aparente.

Todas as arestas, uma expansão

HTTP 208 não fingiu que o grafo era árvore. Conservou relações, estabilizou identidade e limitou o trabalho.

Cada binding aparece porque o caminho é estado real. Cada recurso mantém ID porque não pertence a uma URI. Os descendentes são expandidos uma vez porque a repetição não acrescenta estrutura. A omissão recebe um status porque silêncio sem causa parece perda.

Nenhum caminho se torna centro soberano. Nenhum alias vira cópia. Nenhum ciclo obriga o sistema a inventar objetos infinitos.

A segunda porta permanece na planta; os armários da sala compartilhada não precisam de outra contagem.