Resumo

  • Uma resposta 207 registra linhas que o servidor devolveu sob uma gramática, árbitro, escopo e principal. Ela não prova que todos os recursos foram avaliados.
  • No truncamento, o subconjunto parcial pode ser qualquer parte dos resultados válidos. A ordenação organiza as linhas visíveis, mas não garante as maiores posições globais.

A contagem parou; a coleção talvez não

O caso mais traiçoeiro é uma resposta tecnicamente correta. O servidor devolve 207 Multi-Status, hrefs válidos e propriedades. O consumidor conta cem linhas e encerra a reconciliação. RFC 5323 autoriza o servidor a limitar recursos consumidos pela busca e a deixar de examinar muitos itens que poderiam corresponder.

Quando isso acontece, o árbitro de pesquisa recebe um estado 507 dentro da resposta, e resultados parciais devem ser incluídos quando possível. Esses resultados podem ser qualquer subconjunto do conjunto satisfatório. Se houve DAV:orderby, as linhas devolvidas respeitam a ordem pedida; não se segue que sejam as primeiras de todo o universo.

Um conversor que remove o elemento 507 e preserva só as linhas cria uma falsidade sem alterar nenhuma linha. A completude era uma propriedade do envelope. Perdê-lo transforma trabalho interrompido em censo.

DAV:limit permite ao cliente pedir número máximo ou esforço, mas o servidor pode ignorá-lo. Ordem com limite deveria privilegiar os itens mais altos. Pedido, aplicação efetiva e truncamento continuam eventos separados.

O endereço do árbitro não delimita a população

SEARCH transporta a consulta; a gramática define seu sentido. A Request-URI nomeia o search arbiter, a entidade que aceita e executa. Ela não precisa coincidir com o escopo.

Em DAV:basicsearch, DAV:from declara escopos com href e depth. Zero inclui a própria coleção, um inclui filhos imediatos e infinity inclui descendentes. Referências relativas são resolvidas contra a Request-URI; referências absolutas podem apontar para outro local dentro do suporte e da política do servidor.

Vários escopos são opcionais. Um servidor sem suporte deve falhar, não fingir uma união parcial. Referências de redirecionamento também não são atravessadas automaticamente. Infinity na sintaxe não é recibo de visita a todos os ramos lógicos.

Guardar apenas o predicado não preserva a pergunta. Para repetir a busca, são necessários árbitro, escopo resolvido, profundidade, gramática e opções. Substituir escopo por Request-URI muda a população.

UNKNOWN não é FALSE

As condições usam TRUE, FALSE e UNKNOWN. Só TRUE inclui o recurso. Uma linha ausente pode representar UNKNOWN sem jamais ter sido falsa.

Uma propriedade que produziria resposta não-2xx em PROPFIND é NULL. NULL não é texto vazio: texto vazio é valor definido. Se o principal não tem leitura da propriedade, ela é avaliada como inexistente; conteúdo sem acesso é tratado como GET 4xx. A busca não pode revelar o que GET e PROPFIND esconderiam.

Assim, dois principais executando o mesmo XML podem receber conjuntos diferentes. A ausência pode decorrer de direito, NULL, escopo, truncamento, redirecionamento, índice atrasado ou mutação recente. “Não existe” é apenas uma hipótese.

Esse comportamento é proteção, não inconsistência. O erro surge quando um sistema converte visibilidade relativa em verdade global e toma ação contra um recurso ou usuário sem registrar o principal da consulta.

Descobrir linguagem não prova execução

DASL e DAV:supported-query-grammar-set anunciam gramáticas aceitas. Não são recibos de consulta. Query Schema Discovery pode informar propriedades pesquisáveis, selecionáveis e ordenáveis e operadores opcionais, mas é facultativo.

O schema varia com árbitro e escopo e pode variar com o principal sem expor todos os fatores. Searchable significa disposição para verificar; não garante presença da propriedade em cada recurso.

O URI da gramática identifica uma linguagem e não deve ser baixado só por parecer endereço HTTP. Da mesma forma, score de relevância não é medida portátil. Números de resultados diferentes só são comparáveis, em geral, quando o mesmo mecanismo operou sobre a mesma coleção.

Capacidade, execução e consequência precisam de comprovantes próprios. Uma opção em OPTIONS não prova índice completo; uma propriedade no schema não prova valor atual; um score não prova importância objetiva.

Uma linha pode ser um dos nomes do mesmo recurso

Vários URI podem mapear ao mesmo recurso. O servidor deveria devolver apenas um. DAV:resource-id ajuda a perceber duplicatas, sem eternizar o href escolhido.

Contar linhas como objetos e aliases ausentes como perdas produz erros opostos. O registro conserva href, resource-id, propstat, horário e árbitro. Deduplicação fica explícita como inferência posterior.

Resultados bem-sucedidos não deveriam ser cacheados. Coleções, propriedades, direitos e índices mudam. SEARCH oferece uma observação temporal, não fotografia imutável.

Evidência operacional para uma consulta

Retenha XML exato, gramática, Request-URI, escopos resolvidos, profundidades, opções de redirecionamento e versão, principal, autorização, seleção, árvore de condições, ordem e limite. Retenha 207, todas as respostas e propstat, hrefs, resource-id, scores, 507 e época do índice quando disponível.

Não rotule como completo sem enumeração separada. Não converta ausência em FALSE enquanto UNKNOWN, acesso, escopo ou truncamento existirem. Não compare scores entre sistemas. Não conte descoberta como execução.

Monitore teto repetido, 507 removido, schema variável, diferença para enumeração PROPFIND autorizada, IDs duplicados e entidades XML externas. Consultas caras também são vetor de negação de serviço; parser, orçamento e timeout fazem parte da autoridade do resultado.

RFC 5323 permite perguntar perto dos dados. Ele não autoriza o índice a falar por tudo o que não examinou. Cem linhas são cem observações retornadas, nada além disso sem nova prova.

Fontes