Résumé

  • Une réponse SEARCH 207 documente une exécution sous une grammaire, un arbitre, une portée et une identité donnés ; elle ne garantit pas que toutes les ressources ont été examinées.
  • En cas de troncature, le serveur peut rendre n’importe quel sous-ensemble admissible. Le tri ordonne ce sous-ensemble, sans en faire nécessairement les meilleurs résultats de l’ensemble complet.

Le piège d’une liste impeccable

Une liste mal formée inspire la méfiance. Une liste de cent lignes, bien triée, avec des URI valides, inspire la confiance. RFC 5323 avertit que la seconde peut être plus dangereuse : le serveur a le droit de limiter le travail de recherche et de ne pas examiner de nombreuses ressources qui auraient satisfait le critère.

Le protocole conserve alors le statut HTTP 207 Multi-Status. Il ajoute pour l’URI de l’arbitre un statut 507 et devrait inclure les résultats partiels. Ces lignes peuvent constituer n’importe quel sous-ensemble du résultat théorique. Si un ordre a été demandé, les lignes rendues doivent respecter cet ordre. Rien ne dit qu’elles forment le sommet mondial du classement.

Un intermédiaire qui supprime la ligne 507 mais conserve les lignes de ressources fabrique une fausse exhaustivité. Un entrepôt qui importe seulement les href reproduit la même erreur. Le marqueur de troncature doit suivre les résultats jusque dans la décision qui les utilise.

Le client peut aussi fournir DAV:limit. Il demande un maximum de réponses ou d’effort, mais le serveur peut ignorer cette limite. Avec DAV:orderby, il devrait choisir les éléments les mieux ordonnés. Cette préférence ne remplace ni l’observation du comportement réel ni le signal de troncature produit par le serveur.

L’URI appelée n’est pas nécessairement la collection fouillée

La méthode SEARCH transporte une requête et son résultat ; la grammaire définit la sémantique. La Request-URI désigne l’arbitre de recherche, c’est-à-dire la ressource qui accepte et exécute la requête. Elle n’est pas automatiquement la portée.

Dans DAV:basicsearch, DAV:from contient une ou plusieurs portées. Chaque portée associe un href et une profondeur : zéro pour la collection seule, un pour elle et ses enfants immédiats, infinity pour toute sa descendance. Une référence relative est résolue contre la Request-URI ; une référence absolue peut viser ailleurs, sous réserve des capacités et politiques du serveur.

Une preuve qui conserve les prédicats sans la portée résolue ne peut pas être rejouée. Une preuve qui remplace la portée par l’arbitre interroge potentiellement une autre population. Le support de plusieurs portées est facultatif : si le serveur ne l’offre pas, il doit rejeter la demande au lieu d’en simuler silencieusement une partie.

Les références de redirection constituent une autre frontière. Elles ne sont pas nécessairement suivies. Une profondeur infinie dans la syntaxe ne prouve donc pas que chaque branche logique d’un espace de noms a été parcourue.

UNKNOWN enlève une ligne sans rendre le prédicat faux

Les prédicats de DAV:where utilisent trois valeurs : TRUE, FALSE et UNKNOWN. Seul TRUE place une ressource dans le résultat. L’absence d’une ligne peut donc venir de FALSE, mais aussi d’UNKNOWN.

Une propriété est NULL lorsque PROPFIND lui attribuerait un statut non-2xx. NULL n’est pas la chaîne vide. La chaîne vide est une valeur définie ; NULL décrit l’absence de valeur accessible dans ce contexte. Pour respecter les autorisations, une propriété illisible est évaluée comme si elle n’existait pas, et un contenu illisible comme si GET échouait.

Deux utilisateurs peuvent ainsi envoyer le même XML au même arbitre et recevoir des résultats différents. SEARCH ne doit pas révéler ce que GET ou PROPFIND leur refuserait. La différence reflète le principal et ses droits, pas nécessairement un défaut d’index.

Une ligne absente peut donc être hors portée, cachée, inconnue, non examinée avant la troncature, derrière une redirection, touchée par une mutation récente ou réellement non correspondante. L’interface honnête conserve cette pluralité au lieu d’afficher « n’existe pas ».

Découvrir une grammaire ne prouve pas l’état de l’index

Le champ DASL et la propriété DAV:supported-query-grammar-set annoncent les grammaires disponibles. Cette annonce ne suffit pas pour construire toutes les requêtes valides. Query Schema Discovery peut indiquer quelles propriétés sont recherchables, sélectionnables ou triables, et quels opérateurs optionnels sont acceptés.

QSD reste facultatif. Son résultat dépend de l’arbitre et de la portée, et peut aussi dépendre du principal sans que tous ces facteurs soient exposés. Une propriété marquée searchable signifie que le serveur accepte de la vérifier ; elle ne sera pas forcément définie pour chaque ressource.

Il faut donc séparer capacité et exécution. La grammaire disponible ne prouve pas qu’une requête a été exécutée, que l’index couvrait la collection ou que les propriétés rendues étaient fraîches. L’URI d’une grammaire est un identifiant ; une application ne doit pas la télécharger simplement parce qu’elle ressemble à une URL HTTP.

Les scores sont également locaux. Leur comparaison entre deux recherches n’a en général pas de sens, sauf si le même moteur a travaillé sur la même collection. Transformer un score en mesure portable de pertinence crée une autorité que le protocole n’accorde pas.

Une URI rendue n’est pas forcément une ressource unique

Plusieurs URI de la portée peuvent désigner la même ressource. Le serveur devrait n’en rendre qu’une. La propriété vivante DAV:resource-id aide à repérer des doublons possibles, mais ne rend pas l’href choisi éternel ni exclusif.

Une ligne ne signifie donc pas toujours un objet, et deux alias absents ne signifient pas deux objets disparus. Un registre conserve href, identifiant de ressource, statuts de propriétés, arbitre et heure. La déduplication devient une inférence séparée.

Les réponses réussies ne devraient pas être mises en cache. Collections, droits, propriétés et index peuvent changer. Le résultat est un constat daté, non une vue matérialisée permanente.

Le reçu nécessaire avant une décision

Conservez le corps XML exact, l’identifiant de grammaire, la Request-URI, les portées résolues, les profondeurs, les options de redirection et de version, le principal, le contexte d’autorisation, les propriétés, l’arbre de prédicats, l’ordre et la limite. Pour la réponse, gardez chaque ligne Multi-Status, chaque propstat, les href, les identifiants, les scores, le statut 507 et l’âge de l’index lorsqu’il est disponible.

Ne transformez pas les lignes en inventaire complet sans mécanisme d’énumération supplémentaire. Ne concluez pas FALSE pour une absence tant que portée, droits, UNKNOWN et troncature ne sont pas résolus. Ne comparez pas les scores entre moteurs. Ne confondez pas découverte de grammaire et exécution.

Les alertes les plus utiles détectent un 507 perdu, un plafond de résultats récurrent, un schéma qui change pour le même principal, des identifiants dupliqués, un écart croissant avec une énumération PROPFIND autorisée et des références externes XML. RFC 5323 donne un outil de recherche puissant. Sa fiabilité dépend de la conservation de ses limites.

Sources