Résumé

  • Dans RFC 3648, l’ordre est un état de la collection ; un MOVE au sein du même parent peut conserver la position ou se comporter comme une suppression suivie d’un ajout en fin de liste.
  • La preuve exploitable doit réunir l’ordre attendu, la requête exacte, les droits et verrous, la réponse, une relecture PROPFIND Depth: 1 et l’ordre effectivement présenté.

La séquence d’un corpus peut porter autant de sens que les documents eux-mêmes. Le RFC 3648 en fait un état serveur explicite. Une collection non ordonnée ne promet aucune stabilité entre deux énumérations PROPFIND. Une collection ordonnée doit respecter sa séquence ; chacun de ses membres internes y figure exactement une fois et aucun élément extérieur ne peut y être glissé.

La difficulté apparaît lors d’un renommage interne. Le serveur peut conserver la place du membre, ou réaliser une suppression puis un ajout. Dans ce second modèle, l’absence de Position applique la règle du nouveau membre : placement à la fin. L’édition texte présente cette latitude comme consciente, en attendant un éventuel retour d’expérience. Elle ne permet pas de désigner un comportement réel sans l’observer.

Une collection ne possède qu’un ordre. Plusieurs lectures des mêmes ressources demandent plusieurs collections. L’ordre reste celui de la ressource collection, quelle que soit l’URI par laquelle on y accède, et demeure soumis aux verrous et contrôles d’accès. Les liaisons multiples décrites par le RFC 5842 ne transforment donc pas toutes les collections en une seule séquence universelle.

DAV:ordering-type est protégé. DAV:unordered exclut toute promesse de répétabilité ; DAV:custom signale un ordre sans en imposer une signification portable. Une URI d’ordering-type nomme une sémantique, mais la section sécurité interdit d’en faire un service à interroger automatiquement : un grand nombre de clients pourraient ainsi être dirigés contre une cible.

Le champ Position, toujours inscrit au registre IANA des champs HTTP, permet de demander first, last, before ou after. Il réduit l’ambiguïté de mise en œuvre. Il ne prouve pas que le segment de référence existe encore, que l’appelant est autorisé, que le verrou est satisfait ni que la présentation aval a convergé. Le RFC 3744 rappelle la couche d’autorisation : connaître un nom n’accorde pas le pouvoir de réordonner.

ORDERPATCH offre une opération tout-ou-rien : les instructions sont traitées dans l’ordre du document et, si l’une échoue, l’état précédent doit être rétabli. Cette atomicité est locale à la requête. Elle ne couvre ni cache, ni index, ni navigation rendue. Si la sémantique d’ordre change et que certains membres sont omis, les membres cités passent en tête ; le serveur choisit l’ordre relatif des autres. Une opération atomique peut ainsi laisser volontairement une partie du résultat indéterminée.

La relecture directe est un PROPFIND Depth: 1. Depth: infinity peut entremêler les descendants tout en respectant chaque ordre local ; ce n’est pas une liste globale. Le socle historique vient du RFC 2518, remplacé par le RFC 4918. Aucun des deux ne fait d’un code 2xx une attestation d’interface utilisateur.

Le versionnement trace une autre frontière. Le RFC 3253 fournit DeltaV. Lors d’un UPDATE ou MERGE, RFC 3648 restaure le type d’ordre et l’ordre des membres versionnés ; la place des membres non versionnés reste choisie par le serveur. Une restauration réussie n’implique donc pas une reconstitution intégrale de la lecture visible.

La capacité est facultative et doit être découverte par OPTIONS, la classe ordered-collections, les méthodes et propriétés prises en charge. Le RFC 5689 enrichit MKCOL, sans prouver à lui seul l’acceptation d’une sémantique ordonnée. Les validateurs des RFC 7232 et RFC 9110 peuvent renforcer un déploiement, mais RFC 3648 ne définit aucun jeton de révision propre à l’ordre.

Le vocabulaire de segment vient du RFC 2396, ensuite actualisé par le RFC 3986. Un segment utilisé dans before ou after est un opérande lié à l’appartenance présente, non un identifiant immuable. La provenance du standard se contrôle dans le Datatracker, la fiche RFC Editor, l’historique et les errata, sans en déduire les choix d’un produit.

Les textes de Heng Lu sur la primauté du code exécuté, la spécification initiale minimale et les couches de réalité clarifient la gouvernance : le standard rend l’intention partageable, l’implémentation choisit une option permise, l’observation établit l’état, et le lecteur rencontre encore une couche différente.

Le reçu doit conserver l’identité de la collection, son type d’ordre, les listes complètes avant et après, les capacités, droits et verrous, les octets MOVE ou ORDERPATCH, Position, le segment de référence, la réponse, la version ou le validateur réellement exposé, puis la séquence rendue. L’absence d’un maillon est une incertitude, pas une invitation à la masquer par « opération réussie ».