Aller au contenu principal

RFC 4918 - Extensions HTTP : Création et gestion de versions distribuées sur le Web (WebDAV)

  • Statut: Proposed Standard
  • Publié: June 2007
  • Stream: IETF
  • Remplace: RFC2518
  • Errata: Pas d'errata

Résumé (Abstract)​

La création et la gestion de versions distribuées sur le Web (WebDAV, Web Distributed Authoring and Versioning) se compose d'un ensemble de méthodes, d'en-têtes et de types de contenu accessoires à HTTP/1.1 pour la gestion des propriétés de ressources (Resource Properties), la création et la gestion de collections de ressources (Resource Collections), la manipulation de l'espace de noms des URL (URL Namespace Manipulation) et le verrouillage des ressources (Resource Locking, pour éviter les conflits).

Le RFC 2518 a été publié en février 1999. Cette spécification rend obsolète le RFC 2518 avec des révisions mineures basées sur l'expérience d'interopérabilité.

Statut de ce mémo (Status of This Memo)​

Ce document spécifie un protocole de la filière de normalisation Internet pour la communauté Internet et demande des discussions et des suggestions pour son amélioration. Veuillez vous référer à l'édition actuelle des « Standards officiels des protocoles Internet » (STD 1) pour connaître l'état de normalisation et le statut de ce protocole. La distribution de ce mémo est illimitée.

Copyright (C) The IETF Trust (2007).

Table des matières (Contents)​

Sections principales​

Annexes (Appendices)​

Concepts fondamentaux de WebDAV​

Fonctionnalités clés​

WebDAV étend le protocole HTTP/1.1 avec les capacités fondamentales suivantes :

  1. Propriétés (Properties) : Ajouter, modifier et interroger les métadonnées des ressources Web
  2. Collections : Créer et gérer des structures hiérarchiques de ressources
  3. Verrouillage (Locking) : Prévenir les conflits d'édition concurrente, prenant en charge les verrous exclusifs et partagés
  4. Opérations d'espace de noms (Namespace Operations) : Copier et déplacer des ressources Web

Nouvelles méthodes HTTP​

  • PROPFIND : Récupérer les propriétés d'une ressource
  • PROPPATCH : Modifier les propriétés d'une ressource
  • MKCOL : Créer une collection (similaire à la création d'un répertoire)
  • COPY : Copier une ressource ou une collection
  • MOVE : Déplacer ou renommer une ressource ou une collection
  • LOCK : Verrouiller une ressource pour éviter les conflits
  • UNLOCK : Déverrouiller une ressource

Nouveaux codes d'état HTTP​

  • 207 Multi-Status : Réponse multi-état pour les opérations par lots
  • 422 Unprocessable Entity : La requête était bien formée mais contenait des erreurs sémantiques
  • 423 Locked : La ressource est verrouillée
  • 424 Failed Dependency : La requête a échoué en raison de l'échec d'une requête précédente
  • 507 Insufficient Storage : Espace de stockage insuffisant pour terminer la requête

Cas d'utilisation​

  • Édition collaborative : Plusieurs utilisateurs éditant du contenu Web simultanément
  • Systèmes de gestion de contenu (CMS) : Gestion à distance du contenu de sites Web
  • Partage de fichiers : Téléchargement et téléversement de fichiers via le protocole HTTP
  • Stockage cloud : Implémentation de services de stockage de fichiers basés sur HTTP

1. Introduction​

Ce document décrit une extension du protocole HTTP/1.1 qui permet aux clients d'effectuer des opérations de création de contenu Web à distance. Cette extension fournit un ensemble cohérent de méthodes, d'en-têtes, de formats de corps d'entité de requête et de formats de corps d'entité de réponse qui fournissent des opérations pour :

Propriétés (Properties) : La capacité de créer, supprimer et interroger des informations sur les pages Web, telles que leurs auteurs, dates de création, etc.

Collections : La capacité de créer des ensembles de documents et de récupérer une liste d'appartenance hiérarchique (comme une liste de répertoire dans un système de fichiers).

Verrouillage (Locking) : La capacité d'empêcher plusieurs personnes de travailler sur un document en même temps. Cela empêche le « problème de mise à jour perdue (Lost Update Problem) », dans lequel les modifications sont perdues lorsque d'abord un auteur, puis un autre, écrit des modifications sans fusionner les modifications de l'autre auteur.

Opérations d'espace de noms (Namespace Operations) : La capacité d'instruire le serveur de copier et déplacer des ressources Web, opérations qui modifient le mappage des URL vers les ressources.

Les exigences et la justification de ces opérations sont décrites dans un document complémentaire, « Exigences pour un protocole de création et de gestion de versions distribuées pour le World Wide Web (Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web) » [RFC2291].

Ce document ne spécifie pas les opérations de gestion de versions suggérées par [RFC2291]. Ce travail a été effectué dans un document séparé, « Extensions de gestion de versions pour WebDAV (Versioning Extensions to WebDAV) » [RFC3253].

Les sections ci-dessous fournissent une introduction détaillée aux diverses abstractions WebDAV : propriétés de ressources (Resource Properties, Section 4), collections de ressources (Collections of Resources, Section 5), verrous (Locks, Section 6) en général, et verrous d'écriture (Write Locks, Section 7) spécifiquement.

Ces abstractions sont manipulées par les méthodes HTTP spécifiques à WebDAV (Section 9) et les en-têtes HTTP supplémentaires (Section 10) utilisés avec les méthodes WebDAV. Les considérations générales pour la gestion des requêtes et réponses HTTP dans WebDAV se trouvent dans la Section 8.

Bien que les codes d'état fournis par HTTP/1.1 soient suffisants pour décrire la plupart des conditions d'erreur rencontrées par les méthodes WebDAV, il existe certaines erreurs qui ne s'intègrent pas parfaitement dans les catégories existantes. Cette spécification définit des codes d'état supplémentaires développés pour les méthodes WebDAV (Section 11) et décrit les codes d'état HTTP existants (Section 12) tels qu'utilisés dans WebDAV. Étant donné que certaines méthodes WebDAV peuvent opérer sur de nombreuses ressources, la réponse multi-état (Multi-Status Response, Section 13) a été introduite pour retourner des informations d'état pour plusieurs ressources. Enfin, cette version de WebDAV introduit des éléments XML de précondition et de postcondition (Precondition/Postcondition, Section 16) dans les corps de réponse d'erreur.

WebDAV utilise XML ([REC-XML]) pour les noms de propriétés et certaines valeurs, et utilise également XML pour marshaller des requêtes et réponses complexes. Cette spécification contient des définitions DTD et textuelles de toutes les propriétés (Section 15) et de tous les autres éléments XML (Section 14) utilisés dans le marshalling. WebDAV inclut quelques règles spéciales sur l'extension du marshalling XML de WebDAV de manière rétrocompatible (Section 17).

Pour finir la spécification, il y a des sections sur ce que signifie pour une ressource d'être conforme à cette spécification (Section 18), sur le support de l'internationalisation (Section 19), et sur la sécurité (Section 20).

2. Notational Conventions (Conventions de notation)​

Étant donné que ce document décrit un ensemble d'extensions du protocole HTTP/1.1, le BNF augmenté (Augmented BNF) utilisé ici pour décrire les éléments du protocole est exactement le même que celui décrit dans la Section 2.1 de [RFC2616], y compris les règles concernant les espaces linéaires implicites (Implied Linear Whitespace). Puisque ce BNF augmenté utilise les règles de production de base fournies dans la Section 2.2 de [RFC2616], ces règles s'appliquent également à ce document. Notez qu'il ne s'agit pas de la syntaxe BNF standard utilisée dans d'autres RFC.

Les mots-clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « MAY » et « OPTIONAL » dans ce document doivent être interprétés comme décrit dans [RFC2119].

Correspondance française :

  • MUST (doit) : exigence absolue
  • MUST NOT (ne doit pas) : interdiction absolue
  • REQUIRED (requis) : exigence absolue
  • SHALL (doit) : exigence obligatoire
  • SHALL NOT (ne doit pas) : interdiction obligatoire
  • SHOULD (devrait) : fortement recommandé mais non obligatoire
  • SHOULD NOT (ne devrait pas) : fortement déconseillé mais non interdit
  • RECOMMENDED (recommandé) : pratique recommandée
  • MAY (peut) : permis mais optionnel
  • OPTIONAL (optionnel) : entièrement optionnel

Notez qu'en langage naturel, une propriété comme la propriété « creationdate » dans l'espace de noms XML « DAV: » est parfois appelée « DAV:creationdate » par souci de concision.

3. Terminology (Terminologie)​

Cette section définit les termes clés utilisés dans la spécification WebDAV.

URI/URL​

URI (Uniform Resource Identifier, Identifiant Uniforme de Ressource) et URL (Uniform Resource Locator, Localisateur Uniforme de Ressource), respectivement. Ces termes (et la distinction entre eux) sont définis dans [RFC3986].

URI/URL Mapping (Mappage URI/URL)​

Une relation entre un URI absolu et une ressource. Étant donné qu'une ressource peut représenter des éléments qui ne sont pas récupérables par le réseau, ainsi que ceux qui le sont, il est possible qu'une ressource ait zéro, un ou plusieurs mappages URI. Le mappage d'une ressource à un URI de schéma « http » permet de soumettre des requêtes de protocole HTTP à la ressource en utilisant l'URI.

Path Segment (Segment de chemin)​

Informellement, les caractères trouvés entre les barres obliques (« / ») dans un URI. Formellement, comme défini dans la Section 3.3 de [RFC3986].

Collection​

Informellement, une ressource qui agit également comme un conteneur de références vers des ressources enfants. Formellement, une ressource qui contient un ensemble de mappages entre des segments de chemin et des ressources et répond aux exigences définies dans la Section 5.

Internal Member (of a Collection) (Membre interne d'une collection)​

Informellement, une ressource enfant d'une collection. Formellement, une ressource référencée par un mappage de segment de chemin contenu dans la collection.

Internal Member URL (of a Collection) (URL de membre interne d'une collection)​

Une URL d'un membre interne, composée de l'URL de la collection (incluant la barre oblique finale) plus le segment de chemin identifiant le membre interne.

Member (of a Collection) (Membre d'une collection)​

Informellement, un « descendant » d'une collection. Formellement, un membre interne de la collection, ou, récursivement, un membre d'un membre interne.

Member URL (of a Collection) (URL de membre d'une collection)​

Une URL qui est soit une URL de membre interne de la collection elle-même, soit une URL de membre interne d'un membre de cette collection.

Property (Propriété)​

Une paire nom/valeur qui contient des informations descriptives sur une ressource.

Live Property (Propriété vivante)​

Une propriété dont la sémantique et la syntaxe sont appliquées par le serveur. Par exemple, la propriété vivante DAV:getcontentlength a sa valeur, la longueur de l'entité renvoyée par une requête GET, automatiquement calculée par le serveur.

Dead Property (Propriété morte)​

Une propriété dont la sémantique et la syntaxe ne sont pas appliquées par le serveur. Le serveur enregistre uniquement la valeur d'une propriété morte ; le client est responsable du maintien de la cohérence de la syntaxe et de la sémantique d'une propriété morte.

Principal (Principal)​

Un acteur humain ou informatique distinct qui initie l'accès aux ressources réseau.

State Token (Jeton d'état)​

Un URI qui représente un état d'une ressource. Les jetons de verrou (Lock Tokens) sont les seuls jetons d'état définis dans cette spécification.

4. Data Model for Resource Properties (Modèle de données pour les propriétés de ressources)​

4.1 The Resource Property Model (Le modèle de propriété de ressource)​

Les propriétés sont des morceaux de données qui décrivent l'état d'une ressource. Les propriétés sont des données sur les données.

Les propriétés sont utilisées dans les environnements de création distribuée pour fournir une découverte et une gestion efficaces des ressources. Par exemple, une propriété 'subject' pourrait permettre l'indexation de toutes les ressources par leur sujet, et une propriété 'author' pourrait permettre la découverte des auteurs ayant écrit quels documents.

Le modèle de propriété DAV consiste en des paires nom/valeur. Le nom d'une propriété identifie la syntaxe et la sémantique de la propriété, et fournit une adresse par laquelle référencer sa syntaxe et sa sémantique.

Il existe deux catégories de propriétés: "live" et "dead". Une propriété live a sa syntaxe et sa sémantique imposées par le serveur. Les propriétés live incluent les cas où a) la valeur d'une propriété est protégée et maintenue par le serveur, et b) la valeur de la propriété est maintenue par le client, mais le serveur effectue une vérification syntaxique sur les valeurs soumises. Toutes les instances d'une propriété live donnée DOIVENT se conformer à la définition associée à ce nom de propriété. Une propriété dead a sa syntaxe et sa sémantique imposées par le client; le serveur enregistre simplement la valeur de la propriété textuellement.

4.2 Properties and HTTP Headers (Propriétés et en-têtes HTTP)​

Les propriétés existent déjà, dans un sens limité, dans les en-têtes de message HTTP. Cependant, dans les environnements de création distribuée, un nombre relativement important de propriétés est nécessaire pour décrire l'état d'une ressource, et les définir/retourner toutes via des en-têtes HTTP est inefficace. Ainsi, un mécanisme est nécessaire qui permet à un principal d'identifier un ensemble de propriétés qui l'intéressent et de définir ou récupérer uniquement ces propriétés.

4.3 Property Values (Valeurs de propriété)​

La valeur d'une propriété est toujours un fragment XML bien formé.

XML a été choisi car c'est un format de données structuré flexible et auto-descriptif qui prend en charge des définitions de schéma riches, et en raison de son support pour plusieurs jeux de caractères. La nature auto-descriptive de XML permet d'étendre la valeur de toute propriété en ajoutant des éléments. Les clients ne se briseront pas lorsqu'ils rencontrent des extensions car ils auront toujours les données spécifiées dans le schéma original et DOIVENT ignorer les éléments qu'ils ne comprennent pas.

Le support de XML pour plusieurs jeux de caractères permet à toute propriété lisible par l'homme d'être encodée et lue dans un jeu de caractères familier à l'utilisateur. Le support de XML pour plusieurs langues humaines, utilisant l'attribut "xml:lang", gère les cas où le même jeu de caractères est employé par plusieurs langues humaines. Notez que la portée xml:lang est récursive, donc un attribut xml:lang sur tout élément contenant un élément de nom de propriété s'applique à la valeur de propriété à moins qu'il n'ait été remplacé par un attribut de portée plus locale. Notez qu'une propriété n'a qu'une seule valeur, dans une seule langue (ou la langue PEUT rester non définie); une propriété n'a pas plusieurs valeurs dans différentes langues ou une seule valeur dans plusieurs langues.

Une propriété est toujours représentée par un élément XML consistant en le nom de la propriété, appelé "property name element". L'exemple le plus simple est une propriété vide, qui est différente d'une propriété qui n'existe pas:

<R:title xmlns:R="http://www.example.com/ns/"><R:title>

La valeur de la propriété apparaît à l'intérieur de l'élément de nom de propriété. La valeur peut être n'importe quel type de contenu XML bien formé, y compris du contenu texte uniquement et du contenu mixte. Les serveurs DOIVENT préserver les éléments d'information XML suivants (Information Items, utilisant la terminologie de [REC-XML-INFOSET]) dans le stockage et la transmission des propriétés dead:

Pour l'Element Information Item de nom de propriété lui-même:

  • [namespace name]
  • [local name]
  • [attributes] nommés "xml:lang" ou tout attribut de ce type en portée
  • [children] de type element ou character

Sur tous les Element Information Items dans la valeur de propriété:

  • [namespace name]
  • [local name]
  • [attributes]
  • [children] de type element ou character

Sur les Attribute Information Items dans la valeur de propriété:

  • [namespace name]
  • [local name]
  • [normalized value]

Sur les Character Information Items dans la valeur de propriété:

  • [character code]

Étant donné que les préfixes sont utilisés dans certains vocabulaires XML (XPath et XML Schema, par exemple), les serveurs DEVRAIENT préserver, pour tout Information Item dans la valeur:

  • [prefix]

Les attributs XML Infoset non listés ci-dessus PEUVENT être préservés par le serveur, mais les clients NE DOIVENT PAS compter sur leur préservation. Les règles ci-dessus s'appliqueraient également par défaut aux propriétés live, sauf définition contraire.

Les serveurs DOIVENT ignorer l'attribut XML xml:space s'il est présent et ne jamais l'utiliser pour modifier le traitement des espaces blancs. Les espaces blancs dans les valeurs de propriété sont significatifs.

4.3.1 Exemple - Propriété avec contenu mixte​

Considérons une propriété dead 'author' créée par le client comme suit:

<D:prop xml:lang="en" xmlns:D="DAV:">
  <x:author xmlns:x='http://example.com/ns'>
    <x:name>Jane Doe<x:name>
    <!-- Jane's contact info -->
    &lt;x:uri type='email'
           added='2005-11-26'>mailto:[email protected]&lt;x:uri>
    &lt;x:uri type='web'
           added='2005-11-27'>http://www.example.com&lt;x:uri>
    &lt;x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
      Jane has been working way &lt;h:em>too&lt;h:em> long on the
      long-awaited revision of <![CDATA[&lt;RFC2518>]]>.
    &lt;x:notes>
  &lt;x:author>
&lt;D:prop>

Lorsque cette propriété est demandée, un serveur pourrait retourner:

&lt;D:prop xmlns:D='DAV:'>&lt;author
        xml:lang='en'
        xmlns:x='http://example.com/ns'
        xmlns='http://example.com/ns'
        xmlns:h='http://www.w3.org/1999/xhtml'>
    &lt;x:name>Jane Doe&lt;x:name>
    &lt;x:uri   added="2005-11-26" type="email"
      >mailto:[email protected]&lt;x:uri>
    &lt;x:uri   added="2005-11-27" type="web"
      >http://www.example.com&lt;x:uri>
    &lt;x:notes>
      Jane has been working way &lt;h:em>too&lt;h:em> long on the
      long-awaited revision of &lt;RFC2518&gt;.
    &lt;x:notes>
  &lt;/author>
&lt;D:prop>

Notez dans cet exemple:

  • Le [prefix] pour le nom de propriété lui-même n'a pas été préservé, étant non significatif, alors que toutes les autres valeurs [prefix] ont été préservées,
  • les valeurs d'attribut ont été réécrites avec des guillemets doubles au lieu de guillemets simples (le style de citation n'est pas significatif), et l'ordre des attributs n'a pas été préservé,
  • l'attribut xml:lang a été retourné sur l'élément de nom de propriété lui-même (il était en portée lorsque la propriété a été définie, mais la position exacte dans la réponse n'est pas considérée comme significative tant qu'elle est en portée),
  • les espaces blancs entre les balises ont été préservés partout (pas les espaces blancs entre les attributs),
  • l'encapsulation CDATA a été remplacée par l'échappement de caractères (l'inverse serait également légal),
  • l'élément de commentaire a été supprimé (tout comme l'aurait été un élément d'instruction de traitement).

Note d'implémentation: il existe des cas tels que des scénarios d'édition où les clients peuvent exiger que le contenu XML soit préservé caractère par caractère (tel que l'ordre des attributs ou le style de citation). Dans ce cas, les clients devraient envisager d'utiliser une valeur de propriété texte uniquement en échappant tous les caractères ayant une signification spéciale dans l'analyse XML.

4.4 Property Names (Noms de propriété)​

Un nom de propriété est un identifiant universellement unique qui est associé à un schéma fournissant des informations sur la syntaxe et la sémantique de la propriété.

Parce que le nom d'une propriété est universellement unique, les clients peuvent dépendre d'un comportement cohérent pour une propriété particulière sur plusieurs ressources, sur le même serveur et sur différents serveurs, tant que cette propriété est "live" sur les ressources en question, et que l'implémentation de la propriété live est fidèle à sa définition.

Le mécanisme d'espace de noms XML, qui est basé sur les URI ([RFC3986]), est utilisé pour nommer les propriétés car il empêche les collisions d'espace de noms et offre différents degrés de contrôle administratif.

L'espace de noms des propriétés est plat; c'est-à-dire qu'aucune hiérarchie de propriétés n'est explicitement reconnue. Ainsi, si une propriété A et une propriété A/B existent sur une ressource, il n'y a aucune reconnaissance d'une relation entre les deux propriétés. On s'attend à ce qu'une spécification séparée soit éventuellement produite qui abordera les questions relatives aux propriétés hiérarchiques.

Enfin, il n'est pas possible de définir la même propriété deux fois sur une seule ressource, car cela provoquerait une collision dans l'espace de noms des propriétés de la ressource.

4.5 Source Resources and Output Resources (Ressources source et ressources de sortie)​

Certaines ressources HTTP sont générées dynamiquement par le serveur. Pour ces ressources, il existe vraisemblablement un code source quelque part régissant la façon dont cette ressource est générée. La relation entre les fichiers source et les ressources HTTP de sortie peut être un à un, un à plusieurs, plusieurs à un, ou plusieurs à plusieurs. Il n'existe aucun mécanisme dans HTTP pour déterminer si une ressource est même dynamique, encore moins où existent ses fichiers source ou comment les créer. Bien que ce problème serait utilement résolu, des implémentations WebDAV interopérables ont été largement déployées sans résoudre réellement ce problème, en ne traitant que des ressources statiques. Ainsi, le problème source vs. sortie n'est pas résolu dans cette spécification et a été reporté à un document séparé.

5. Collections of Web Resources (Collections de ressources Web)​

Cette section fournit une description d'un type de ressource Web, la collection, et discute de ses interactions avec l'espace de noms d'URL HTTP et avec les méthodes HTTP. Le but d'une ressource de collection est de modéliser des objets de type collection (par exemple, des répertoires de système de fichiers) dans l'espace de noms d'un serveur.

Toutes les ressources conformes à DAV DOIVENT prendre en charge le modèle d'espace de noms d'URL HTTP spécifié ici.

5.1 HTTP URL Namespace Model (Modèle d'espace de noms d'URL HTTP)​

L'espace de noms d'URL HTTP est un espace de noms hiérarchique où la hiérarchie est délimitée par le caractère "/".

Un espace de noms d'URL HTTP est dit cohérent s'il remplit les conditions suivantes: pour chaque URL dans la hiérarchie HTTP, il existe une collection qui contient cette URL en tant qu'URL de membre interne. La racine, ou collection de niveau supérieur de l'espace de noms considéré, est exemptée de la règle précédente. La collection de niveau supérieur de l'espace de noms considéré n'est pas nécessairement la collection identifiée par le chemin absolu '/' -- elle peut être identifiée par un ou plusieurs segments de chemin (par exemple, /servlets/webdav/...)

Ni HTTP/1.1 ni WebDAV n'exigent que l'ensemble de l'espace de noms d'URL HTTP soit cohérent -- une ressource compatible WebDAV peut ne pas avoir de collection parente. Cependant, certaines méthodes WebDAV sont interdites de produire des résultats qui causent des incohérences d'espace de noms.

Comme cela est implicite dans [RFC2616] et [RFC3986], toute ressource, y compris les ressources de collection, PEUT être identifiée par plus d'un URI. Par exemple, une ressource pourrait être identifiée par plusieurs URL HTTP.

5.2 Collection Resources (Ressources de collection)​

Les ressources de collection diffèrent des autres ressources en ce qu'elles agissent également comme des conteneurs. Certaines méthodes HTTP s'appliquent uniquement à une collection, mais certaines s'appliquent à certaines ou à toutes les ressources à l'intérieur du conteneur défini par la collection. Lorsque la portée d'une méthode n'est pas claire, le client peut spécifier quelle profondeur appliquer. La profondeur peut être soit zéro niveau (uniquement la collection), un niveau (la collection et les ressources directement contenues), ou des niveaux infinis (la collection et toutes les ressources contenues récursivement).

L'état d'une collection consiste au moins en un ensemble de mappages entre des segments de chemin et des ressources, et un ensemble de propriétés sur la collection elle-même. Dans ce document, une ressource B sera dite être contenue dans la ressource de collection A s'il existe un mappage de segment de chemin qui mappe à B et qui est contenu dans A. Une collection DOIT contenir au plus un mappage pour un segment de chemin donné, c'est-à-dire qu'il est illégal d'avoir le même segment de chemin mappé à plus d'une ressource.

Les propriétés définies sur les collections se comportent exactement comme les propriétés sur les ressources non-collection. Une collection PEUT avoir un état supplémentaire tel que des corps d'entité retournés par GET.

Pour toutes les ressources conformes à WebDAV A et B, identifiées par les URL "U" et "V", respectivement, telles que "V" est égale à "U/SEGMENT", A DOIT être une collection qui contient un mappage de "SEGMENT" à B. Donc, si la ressource B avec l'URL http://example.com/bar/blah est conforme à WebDAV et si la ressource A avec l'URL http://example.com/bar/ est conforme à WebDAV, alors la ressource A doit être une collection et doit contenir exactement un mappage de "blah" à B.

Bien que généralement un mappage consiste en un seul segment et une ressource, en général, un mappage consiste en un ensemble de segments et une ressource. Cela permet à un serveur de traiter un ensemble de segments comme équivalents (c'est-à-dire, soit tous les segments sont mappés à la même ressource, soit aucun des segments n'est mappé à une ressource). Par exemple, un serveur qui effectue un pliage de casse sur les segments traitera les segments "ab", "Ab", "aB" et "AB" comme équivalents. Un client peut alors utiliser n'importe lequel de ces segments pour identifier la ressource. Notez qu'un résultat PROPFIND sélectionnera l'un de ces segments équivalents pour identifier le mappage, il y aura donc un élément de réponse PROPFIND par mappage, et non un par segment dans le mappage.

Les ressources de collection PEUVENT avoir des mappages vers des ressources non conformes à WebDAV dans la hiérarchie d'espace de noms d'URL HTTP, mais ne sont pas obligées de le faire. Par exemple, si la ressource X avec l'URL http://example.com/bar/blah n'est pas conforme à WebDAV et que la ressource A avec l'URL http://example.com/bar/ identifie une collection WebDAV, alors A peut ou non avoir un mappage de "blah" à X.

Si une ressource conforme à WebDAV n'a pas de membres internes conformes à WebDAV dans la hiérarchie d'espace de noms d'URL HTTP, alors la ressource conforme à WebDAV n'est pas tenue d'être une collection.

Il existe une convention établie selon laquelle lorsqu'une collection est référencée par son nom sans barre oblique finale, le serveur PEUT traiter la demande comme si la barre oblique finale était présente. Dans ce cas, il DEVRAIT retourner un en-tête Content-Location dans la réponse, pointant vers l'URL se terminant par "/". Par exemple, si un client invoque une méthode sur http://example.com/blah (sans barre oblique finale), le serveur peut répondre comme si l'opération était invoquée sur http://example.com/blah/ (barre oblique finale), et devrait retourner un en-tête Content-Location avec la valeur http://example.com/blah/. Partout où un serveur produit une URL faisant référence à une collection, le serveur DEVRAIT inclure la barre oblique finale. En général, les clients DEVRAIENT utiliser la forme avec barre oblique finale des noms de collection. Si les clients n'utilisent pas la forme avec barre oblique finale, le client doit être prêt à voir une réponse de redirection. Les clients trouveront la propriété DAV:resourcetype plus fiable que l'URL pour déterminer si une ressource est une collection.

Les clients DOIVENT être capables de prendre en charge le cas où les ressources WebDAV sont contenues à l'intérieur de ressources non-WebDAV. Par exemple, si une réponse OPTIONS de http://example.com/servlet/dav/collection indique un support WebDAV, le client ne peut pas supposer que http://example.com/servlet/dav/ ou son parent sont nécessairement des collections WebDAV.

Un scénario typique dans lequel les URL mappées n'apparaissent pas comme membres de leur collection parente est le cas où un serveur permet des liens ou des redirections vers des ressources non-WebDAV. Par exemple, "/col/link" pourrait ne pas apparaître comme membre de "/col/", bien que le serveur répondrait avec un statut 302 à une demande GET vers "/col/link"; ainsi, l'URL "/col/link" serait effectivement mappée. De même, une page générée dynamiquement pourrait avoir un mappage d'URL de "/col/index.html", ainsi cette ressource pourrait répondre avec un 200 OK à une demande GET mais ne pas apparaître comme membre de "/col/".

Certains mappages vers même des ressources conformes à WebDAV pourraient ne pas apparaître dans la collection parente. Un exemple pour ce cas sont les serveurs qui prennent en charge plusieurs URL d'alias pour chaque ressource conforme à WebDAV. Un serveur peut implémenter des URL insensibles à la casse, ainsi "/col/a" et "/col/A" identifient la même ressource, mais seul "a" ou "A" est rapporté lors de la liste des membres de "/col". Dans les cas où un serveur traite un ensemble de segments comme équivalents, le serveur DOIT exposer un seul segment préféré par mappage, choisi de manière cohérente, dans les réponses PROPFIND.

6. Locking (Verrouillage)​

La capacité de verrouiller une ressource fournit un mécanisme pour sérialiser l'accès à cette ressource. En utilisant un verrou, un client de création peut fournir une garantie raisonnable qu'un autre principal ne modifiera pas une ressource pendant qu'elle est en cours d'édition. De cette manière, un client peut prévenir le problème de la « mise à jour perdue (Lost Update) ».

Cette spécification permet aux verrous de varier sur deux paramètres spécifiés par le client : le nombre de principaux impliqués (verrous exclusifs vs. verrous partagés) et le type d'accès à accorder. Ce document définit le verrouillage pour un seul type d'accès : écriture (Write). Cependant, la syntaxe est extensible et permet la spécification éventuelle du verrouillage pour d'autres types d'accès.

6.1 Lock Model (Modèle de verrou)​

Cette section fournit une description non normative du verrouillage WebDAV.

Un verrou est identifié par un jeton de verrou (Lock Token). Les jetons de verrou sont des URLs et peuvent être transmis via HTTP. Un jeton de verrou est associé à un seul verrou.

Les verrous peuvent être exclusifs ou partagés. Le type de verrou détermine comment le serveur traite les requêtes sur la ressource verrouillée :

Verrou exclusif (Exclusive Lock) :

  • Seul le principal qui a créé le verrou peut modifier la ressource
  • Empêche tout autre principal d'obtenir un verrou conflictuel

Verrou partagé (Shared Lock) :

  • Plusieurs principaux peuvent détenir des verrous partagés
  • Tous les principaux détenant des verrous partagés peuvent modifier la ressource
  • Empêche les principaux ne détenant pas de verrous de modifier la ressource

Les verrous peuvent avoir différentes portées :

  • Verrou direct (Direct Lock) : Le verrou s'applique directement à la ressource
  • Verrou de profondeur (Depth Lock) : Le verrou s'applique à la ressource et à tous ses membres

Pour les collections, la profondeur peut être spécifiée :

  • Depth: 0 : Verrouille uniquement la collection elle-même
  • Depth: infinity : Verrouille la collection et tous ses membres (récursivement)

6.2 Exclusive vs. Shared Locks (Verrous exclusifs vs. verrous partagés)​

Le type de verrou le plus courant est le verrou exclusif (Exclusive Lock). Le but d'un verrou exclusif est d'imposer une politique d'édition d'un principal particulier. Une utilisation courante d'un verrou exclusif est d'empêcher différents principaux de modifier une ressource pendant une longue session de création.

Les verrous partagés (Shared Locks) sont conçus pour prendre en charge la création collaborative, où un groupe de principaux doit modifier une ressource simultanément. La caractéristique clé des verrous partagés est que plusieurs principaux peuvent détenir des verrous partagés, mais les verrous exclusifs excluent tous les autres verrous.

Table de compatibilité des verrous :

État actuelDemande de verrou partagéDemande de verrou exclusif
Aucun✅ Vrai✅ Vrai
Verrou partagé✅ Vrai❌ Faux
Verrou exclusif❌ Faux❌ Faux

6.3 Required Support (Support requis)​

Un serveur doit (MUST) prendre en charge les verrous d'écriture exclusifs (Exclusive Write Locks).

Un serveur peut (MAY) prendre en charge les verrous d'écriture partagés (Shared Write Locks). Si un serveur ne prend pas en charge les verrous d'écriture partagés, le serveur doit (MUST) retourner une erreur lorsqu'un client demande un verrou d'écriture partagé.

6.4 Lock Creator and Privileges (Créateur de verrou et privilèges)​

Un verrou est associé au principal qui a créé le verrou. Seuls les principaux avec le jeton de verrou approprié peuvent déverrouiller une ressource. Cela garantit que le créateur du verrou a le contrôle sur le cycle de vie du verrou.

Le principal créant un verrou doit avoir les privilèges nécessaires pour créer des verrous sur la ressource. Les exigences de privilèges spécifiques sont déterminées par la politique de contrôle d'accès du serveur.

6.5 Lock Tokens (Jetons de verrou)​

Un jeton de verrou (Lock Token) est une URL qui identifie de manière unique un verrou. Les jetons de verrou utilisent généralement le schéma URI opaquelocktoken: (voir Annexe C).

Caractéristiques des jetons de verrou :

  • Unicité globale : Chaque jeton de verrou est globalement unique
  • Imprévisibilité : Les jetons de verrou doivent être imprévisibles pour empêcher l'accès non autorisé
  • Format URL : Les jetons de verrou sont des URLs valides

Exemple de jeton de verrou :

opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Les clients soumettent des jetons de verrou en :

  • Incluant le jeton de verrou dans l'en-tête If
  • Incluant le jeton de verrou dans l'en-tête Lock-Token (pour la méthode UNLOCK uniquement)

6.6 Lock Timeout (Délai d'expiration du verrou)​

Les verrous ont une durée de vie limitée. Le serveur attribue une valeur de délai d'expiration à chaque verrou, après quoi le verrou expire automatiquement.

Caractéristiques du délai d'expiration :

  • Les clients peuvent suggérer une valeur de délai d'expiration dans l'en-tête de requête Timeout
  • Les serveurs peuvent ignorer la suggestion du client et attribuer leur propre valeur de délai d'expiration
  • Les serveurs doivent (MUST) retourner la valeur de délai d'expiration réelle dans la réponse de verrou
  • Les clients peuvent prolonger la durée de vie du verrou en rafraîchissant le verrou

Format du délai d'expiration :

Timeout: Second-4100
Timeout: Infinite

Meilleures pratiques :

  • Les serveurs devraient (SHOULD) permettre aux clients de rafraîchir les verrous
  • Les clients devraient (SHOULD) rafraîchir périodiquement les verrous à long terme
  • Les clients devraient (SHOULD) déverrouiller les ressources une fois l'édition terminée

6.7 Lock Capability Discovery (Découverte des capacités de verrouillage)​

Avant de tenter de verrouiller une ressource, les clients peuvent découvrir les capacités de verrouillage du serveur en utilisant la méthode OPTIONS. L'en-tête DAV dans la réponse indique la classe de conformité WebDAV du serveur, qui inclut le support du verrouillage.

6.8 Active Lock Discovery (Découverte des verrous actifs)​

Les clients peuvent découvrir les verrous actifs sur une ressource en utilisant la méthode PROPFIND pour récupérer la propriété DAV:lockdiscovery. Cette propriété contient des informations sur tous les verrous actifs sur la ressource, y compris le type de verrou, la portée, la profondeur, le propriétaire, le délai d'expiration et le jeton de verrou.

7. Write Lock (Verrou d'écriture)​

Cette section décrit le verrou d'écriture (Write Lock), le seul type de verrou défini dans cette spécification. Un verrou d'écriture est un verrou qui accorde au propriétaire du verrou le droit de modifier la ressource. Le propriétaire du verrou est le principal qui a créé le verrou.

7.1 Write Locks and Properties (Verrous d'écriture et propriétés)​

Bien que ceux qui n'ont pas de verrou d'écriture ne puissent pas modifier le contenu d'une ressource, ils peuvent (MAY) modifier les propriétés mortes de la ressource. Cela permet, par exemple, à un principal d'ajouter des commentaires à une ressource verrouillée sans avoir besoin d'un accès en écriture.

Les propriétés vivantes ont généralement une sémantique imposée par le serveur. Le serveur a donc le pouvoir discrétionnaire de déterminer si et comment autoriser les modifications des propriétés vivantes lorsqu'une ressource est verrouillée. Par exemple, un serveur peut (MAY) autoriser la modification des propriétés vivantes même lorsqu'une ressource est verrouillée.

7.2 Avoiding Lost Updates (Éviter les mises à jour perdues)​

Le but des verrous d'écriture est d'empêcher les mises à jour perdues. Une mise à jour perdue se produit lorsque plusieurs principaux tentent de modifier une ressource sans coordination, ce qui entraîne l'écrasement des modifications d'un ou plusieurs principaux par des mises à jour ultérieures.

Les verrous d'écriture fournissent un mécanisme de sérialisation : seul le détenteur du verrou peut modifier la ressource verrouillée. Cela empêche le problème de mise à jour perdue en garantissant que les modifications se produisent séquentiellement plutôt que simultanément.

Exemple de scénario de mise à jour perdue (sans verrouillage) :

  1. L'utilisateur A récupère la version 1 de la ressource
  2. L'utilisateur B récupère la version 1 de la ressource
  3. L'utilisateur A modifie et enregistre → crée la version 2
  4. L'utilisateur B modifie (basé sur la version 1) et enregistre → crée la version 3, écrasant les modifications de A

Avec verrou d'écriture :

  1. L'utilisateur A verrouille la ressource
  2. L'utilisateur B tente de modifier → reçoit une erreur 423 Locked
  3. L'utilisateur A modifie et déverrouille
  4. L'utilisateur B peut maintenant verrouiller et modifier

7.3 Write Locks and Unmapped URLs (Verrous d'écriture et URLs non mappées)​

Une requête LOCK réussie sur une URL non mappée crée une ressource vide qui est verrouillée. Ce mécanisme permet aux clients de réserver une URL avant que le contenu de la ressource ne soit créé.

Lorsqu'une ressource vide verrouillée est créée :

  • La ressource n'a pas de contenu (entité de longueur zéro)
  • La ressource est verrouillée avec le verrou spécifié
  • Un PUT ou MKCOL ultérieur peut ajouter du contenu à la ressource
  • Le jeton de verrou doit être soumis avec la requête PUT ou MKCOL

Ce mécanisme de « ressource lock-null » est décrit en détail dans l'Annexe D.

7.4 Write Locks and Collections (Verrous d'écriture et collections)​

Un verrou d'écriture sur une collection verrouille la ressource de collection elle-même, empêchant les modifications de l'appartenance de la collection (ajout ou suppression de membres internes).

Lorsqu'un verrou de profondeur infinie est appliqué à une collection :

  • La collection elle-même est verrouillée
  • Tous les membres internes sont verrouillés
  • Toutes les ressources descendantes sont verrouillées récursivement
  • Les nouveaux membres ajoutés à la collection sont automatiquement verrouillés

Héritage du verrou : Lorsqu'une nouvelle ressource est ajoutée à une collection verrouillée (avec profondeur infinie), la nouvelle ressource hérite du verrou de la collection parente.

7.5 Write Locks and the If Request Header (Verrous d'écriture et l'en-tête de requête If)​

Les clients soumettent des jetons de verrou en utilisant l'en-tête de requête If. Cet en-tête permet l'exécution conditionnelle de méthodes basée sur la présence de jetons de verrou.

La syntaxe de l'en-tête If prend en charge :

  • Des jetons de verrou uniques
  • Plusieurs jetons de verrou (pour plusieurs verrous)
  • Des listes étiquetées (associant des jetons à des URLs spécifiques)
  • Des conditions NOT (exigeant l'absence de verrous)

7.5.1 Example - Write Lock and COPY (Exemple - Verrou d'écriture et COPY)​

COPY /source HTTP/1.1
Host: example.com
Destination: http://example.com/destination
If: `http://example.com/destination` (&lt;opaquelocktoken:token123>)

Cette requête copie /source vers /destination, mais seulement si le client détient le jeton de verrou pour /destination.

7.5.2 Example - Deleting a Member of a Locked Collection (Exemple - Suppression d'un membre d'une collection verrouillée)​

DELETE /folder/file.txt HTTP/1.1
Host: example.com
If: `http://example.com/folder/` (&lt;opaquelocktoken:folder-token>)

Pour supprimer un membre d'une collection verrouillée, le client doit soumettre le jeton de verrou pour la collection.

7.6 Write Locks and COPY/MOVE (Verrous d'écriture et COPY/MOVE)​

La méthode COPY crée une nouvelle ressource à la destination. La nouvelle ressource n'est PAS automatiquement verrouillée, même si la source était verrouillée. Les verrous ne sont pas copiés.

La méthode MOVE est sémantiquement équivalente à COPY suivi de DELETE. Le verrou sur la source est supprimé lorsque la ressource est déplacée. La destination n'est pas automatiquement verrouillée.

Si la destination d'un COPY ou MOVE est verrouillée, le client doit soumettre le jeton de verrou approprié pour écraser la destination.

7.7 Refreshing Write Locks (Rafraîchissement des verrous d'écriture)​

Les verrous ont des durées de vie finies. Pour empêcher l'expiration prématurée du verrou, les clients peuvent rafraîchir les verrous en soumettant une requête LOCK avec :

  • Le même jeton de verrou dans l'en-tête If
  • Aucun corps de requête (ou un élément lockinfo vide)

Le serveur répond avec la nouvelle valeur de délai d'expiration. Le rafraîchissement du verrou permet des sessions d'édition à long terme sans expiration du verrou.

Exemple de rafraîchissement de verrou :

LOCK /resource HTTP/1.1
Host: example.com
If: (&lt;opaquelocktoken:token123>)
Timeout: Second-3600

Le serveur prolonge le délai d'expiration du verrou et retourne la nouvelle heure d'expiration.

8. General Request and Response Handling (Traitement général des requêtes et des réponses)​

8.1 Precedence in Error Handling (Priorité dans le traitement des erreurs)​

Les serveurs DOIVENT retourner les erreurs d'autorisation de préférence aux autres erreurs. Cela évite de divulguer des informations sur les ressources protégées (par exemple, un client qui découvre qu'une ressource cachée existe en voyant une réponse 423 Locked à une requête anonyme vers la ressource).

8.2 Use of XML (Utilisation de XML)​

Dans HTTP/1.1, les informations de paramètres de méthode étaient exclusivement encodées dans les en-têtes HTTP. Contrairement à HTTP/1.1, WebDAV encode les informations de paramètres de méthode soit dans un corps d'entité de requête XML ([REC-XML]), soit dans un en-tête HTTP. L'utilisation de XML pour encoder les paramètres de méthode a été motivée par la capacité d'ajouter des éléments XML supplémentaires aux structures existantes, offrant une extensibilité; et par la capacité de XML d'encoder des informations dans des jeux de caractères ISO 10646, offrant un support d'internationalisation.

En plus d'encoder les paramètres de méthode, XML est utilisé dans WebDAV pour encoder les réponses des méthodes, offrant les avantages d'extensibilité et d'internationalisation de XML pour la sortie de méthode, ainsi que l'entrée.

Lorsque XML est utilisé pour un corps de requête ou de réponse, le type Content-Type DEVRAIT être application/xml. Les implémentations DOIVENT accepter à la fois text/xml et application/xml dans les corps de requête et de réponse. L'utilisation de text/xml est déconseillée.

Tous les clients et ressources conformes à DAV DOIVENT utiliser des analyseurs XML conformes à [REC-XML] et [REC-XML-NAMES]. Tout XML utilisé dans les requêtes ou les réponses DOIT être, au minimum, bien formé et utiliser correctement les espaces de noms. Si un serveur reçoit du XML qui n'est pas bien formé, alors le serveur DOIT rejeter l'ensemble de la requête avec un 400 (Bad Request). Si un client reçoit du XML qui n'est pas bien formé dans une réponse, alors le client NE DOIT PAS supposer quoi que ce soit sur le résultat de la méthode exécutée et DEVRAIT traiter le serveur comme dysfonctionnel.

Notez que le traitement de XML soumis par une source non fiable peut causer des risques liés à la confidentialité, à la sécurité et à la qualité du service (voir Section 20). Les serveurs PEUVENT rejeter les requêtes douteuses (même si elles consistent en XML bien formé), par exemple, avec un code de statut 400 (Bad Request) et un corps de réponse optionnel expliquant le problème.

8.3 URL Handling (Traitement des URL)​

Les URL apparaissent à de nombreux endroits dans les requêtes et les réponses. L'expérience d'interopérabilité avec [RFC2518] a montré que de nombreux clients analysant les réponses Multi-Status n'ont pas complètement implémenté la résolution de référence complète définie dans la Section 5 de [RFC3986]. Ainsi, les serveurs en particulier doivent être prudents dans le traitement des URL dans les réponses, pour s'assurer que les clients ont suffisamment de contexte pour pouvoir interpréter toutes les URL. Les règles de cette section s'appliquent non seulement aux URL de ressource dans l'élément 'href' dans les réponses Multi-Status, mais aussi aux URL de ressource des en-têtes Destination et If.

L'expéditeur a le choix entre deux approches: utiliser une référence relative, qui est résolue par rapport au Request-URI, ou un URI complet. Un serveur DOIT s'assurer que chaque valeur 'href' dans une réponse Multi-Status utilise le même format.

WebDAV n'utilise qu'une forme de référence relative dans ses extensions, le chemin absolu.

Simple-ref = absolute-URI | ( path-absolute [ "?" query ] )

Les productions absolute-URI, path-absolute et query sont définies dans les Sections 4.3, 3.3 et 3.4 de [RFC3986].

Dans les productions Simple-ref, les expéditeurs NE DOIVENT PAS:

  • utiliser des segments de points ("." ou ".."), ou
  • avoir des préfixes qui ne correspondent pas au Request-URI (en utilisant les règles de comparaison définies dans la Section 3.2.3 de [RFC2616]).

Les identifiants de collections DEVRAIENT se terminer par un caractère '/'.

8.3.1 Exemple - Traitement correct des URL​

Considérons la collection http://example.com/sample/ avec l'URL de membre interne http://example.com/sample/a%20test et la requête PROPFIND ci-dessous:

Requête:

PROPFIND /sample/ HTTP/1.1
Host: example.com
Depth: 1

Dans ce cas, le serveur devrait retourner deux éléments 'href' contenant soit

  • http://example.com/sample/ et http://example.com/sample/a%20test, ou
  • /sample/ et /sample/a%20test

Notez que même si le serveur peut stocker la ressource membre en interne comme 'a test', elle doit être encodée en pourcentage lorsqu'elle est utilisée dans une référence URI (voir Section 2.1 de [RFC3986]). Notez également qu'un URI légal peut toujours contenir des caractères qui doivent être échappés dans les données de caractères XML, tels que le caractère esperluette.

8.4 Required Bodies in Requests (Corps requis dans les requêtes)​

Certaines de ces nouvelles méthodes ne définissent pas de corps. Les serveurs DOIVENT examiner toutes les requêtes pour un corps, même lorsqu'un corps n'était pas attendu. Dans les cas où un corps de requête est présent mais serait ignoré par un serveur, le serveur DOIT rejeter la requête avec 415 (Unsupported Media Type). Cela informe le client (qui tentait peut-être d'utiliser une extension) que le corps n'a pas pu être traité comme le client l'avait prévu.

8.5 HTTP Headers for Use in WebDAV (En-têtes HTTP à utiliser dans WebDAV)​

HTTP définit de nombreux en-têtes qui peuvent être utilisés dans les requêtes et réponses WebDAV. Tous ne sont pas appropriés dans toutes les situations et certaines interactions peuvent être indéfinies. Notez que HTTP 1.1 requiert l'en-tête Date dans toutes les réponses si possible (voir Section 14.18, [RFC2616]).

Le serveur DOIT effectuer des vérifications d'autorisation avant de vérifier tout en-tête conditionnel HTTP.

8.6 ETag​

HTTP 1.1 recommande l'utilisation d'ETags plutôt que de dates de modification, pour le contrôle du cache, et il existe des raisons encore plus fortes de préférer les ETags pour la création. L'utilisation correcte des ETags est encore plus importante dans un environnement de création distribuée, car les ETags sont nécessaires avec les verrous pour éviter le problème de mise à jour perdue. Un client peut échouer à renouveler un verrou, par exemple, lorsque le verrou expire et que le client est accidentellement hors ligne ou au milieu d'un long téléchargement. Lorsqu'un client échoue à renouveler le verrou, il est tout à fait possible que la ressource puisse encore être reverrouillée et que l'utilisateur puisse continuer à éditer, tant qu'aucun changement n'a été effectué entre-temps. Les ETags sont nécessaires pour que le client puisse distinguer ce cas. Sinon, le client est forcé de demander à l'utilisateur s'il faut écraser la ressource sur le serveur sans même pouvoir dire à l'utilisateur si elle a changé. Les horodatages ne résolvent pas ce problème aussi bien que les ETags.

Les ETags forts sont beaucoup plus utiles pour les cas d'utilisation de création que les ETags faibles (voir Section 13.3.3 de [RFC2616]). L'équivalence sémantique peut être un concept utile mais cela dépend du type de document et du type d'application, et l'interopérabilité pourrait nécessiter un accord ou une norme en dehors de la portée de cette spécification et de HTTP. Notez également que les ETags faibles ont certaines restrictions dans HTTP, par exemple, ceux-ci ne peuvent pas être utilisés dans les en-têtes If-Match.

Notez que la signification d'un ETag dans une réponse PUT n'est clairement définie ni dans ce document ni dans RFC 2616 (c'est-à-dire, si l'ETag signifie que la ressource est équivalente octet par octet au corps de la requête PUT, ou si le serveur aurait pu apporter des modifications mineures au formatage ou au contenu du document lors du stockage). Ceci est un problème HTTP, pas purement un problème WebDAV.

Parce que les clients peuvent être forcés de demander aux utilisateurs ou de rejeter le contenu modifié si l'ETag change, un serveur WebDAV NE DEVRAIT PAS changer l'ETag (ou le temps Last-Modified) pour une ressource qui a un corps et un emplacement inchangés. L'ETag représente l'état du corps ou du contenu de la ressource. Il n'y a pas de moyen similaire de savoir si les propriétés ont changé.

8.7 Including Error Response Bodies (Inclusion de corps de réponse d'erreur)​

HTTP et WebDAV n'utilisaient pas les corps de la plupart des réponses d'erreur pour des informations analysables par machine jusqu'à ce que la spécification pour les Extensions de Versioning à WebDAV introduise un mécanisme pour inclure des informations plus spécifiques dans le corps d'une réponse d'erreur (Section 1.6 de [RFC3253]). Le mécanisme de corps d'erreur est approprié à utiliser avec toute réponse d'erreur qui peut prendre un corps mais n'a pas déjà un corps défini. Le mécanisme est particulièrement approprié lorsqu'un code de statut peut signifier beaucoup de choses (par exemple, 400 Bad Request peut signifier que des en-têtes requis sont manquants, que les en-têtes sont incorrectement formatés, et bien plus encore). Ce mécanisme de corps d'erreur est couvert dans la Section 16.

8.8 Impact of Namespace Operations on Cache Validators (Impact des opérations d'espace de noms sur les validateurs de cache)​

Notez que les en-têtes de réponse HTTP "Etag" et "Last-Modified" (voir [RFC2616], Sections 14.19 et 14.29) sont définis par URL (pas par ressource), et sont utilisés par les clients pour la mise en cache. Par conséquent, les serveurs doivent s'assurer que l'exécution de toute opération qui affecte l'espace de noms d'URL (telle que COPY, MOVE, DELETE, PUT ou MKCOL) préserve leur sémantique, en particulier:

  • Pour toute URL donnée, la valeur "Last-Modified" DOIT s'incrémenter chaque fois que la représentation retournée lors du GET change (dans les limites de la résolution de l'horodatage).
  • Pour toute URL donnée, une valeur "ETag" NE DOIT PAS être réutilisée pour différentes représentations retournées par GET.

En pratique, cela signifie que les serveurs

  • pourraient devoir incrémenter les horodatages "Last-Modified" pour chaque ressource à l'intérieur de l'espace de noms de destination d'une opération d'espace de noms à moins qu'ils ne puissent le faire de manière plus sélective, et
  • de même, pourraient devoir réaffecter les valeurs "ETag" pour ces ressources (à moins que le serveur n'alloue des balises d'entité de manière à ce qu'elles soient uniques dans tout l'espace de noms d'URL géré par le serveur).

Notez que ces considérations s'appliquent également à des cas d'utilisation spécifiques, tels que l'utilisation de PUT pour créer une nouvelle ressource à une URL qui a été mappée auparavant, mais qui a été supprimée depuis.

9. HTTP Methods for Distributed Authoring (Méthodes HTTP pour la création distribuée)​

Ce chapitre décrit les méthodes HTTP définies par WebDAV et les extensions aux méthodes HTTP existantes.

Aperçu des méthodes WebDAV​

MéthodeButCible
PROPFINDRécupérer les propriétésRessource ou collection
PROPPATCHModifier les propriétésRessource
MKCOLCréer une collectionURL non mappée
COPYCopier une ressourceSource et destination
MOVEDéplacer/renommerSource et destination
LOCKVerrouiller une ressourceRessource ou collection
UNLOCKDéverrouiller une ressourceRessource verrouillée

9.1 Méthode PROPFIND​

PROPFIND récupère les propriétés définies sur la ressource identifiée par le Request-URI.

Types de requête : propname, allprop, prop, allprop + include

9.2 Méthode PROPPATCH​

PROPPATCH modifie les propriétés d'une ressource.

Opérations : set (créer/mettre à jour), remove (supprimer)

Atomicité : Toutes les opérations doivent (MUST) réussir ou échouer ensemble.

9.3 Méthode MKCOL​

MKCOL crée une nouvelle ressource de collection au Request-URI.

9.4 GET, HEAD pour les collections​

GET et HEAD appliqués à une collection peuvent (MAY) retourner une liste de répertoires HTML.

9.5 POST pour les collections​

POST ajoute des membres à une collection. Le serveur détermine l'URL du nouveau membre.

9.6 Méthode DELETE​

DELETE supprime la ressource identifiée par le Request-URI.

Pour les collections : Supprime la collection et tous les membres récursivement.

9.7 Méthode PUT​

PUT crée ou met à jour une ressource.

9.8 Méthode COPY​

COPY crée un duplicata de la ressource source à la destination.

En-têtes : Destination (requis), Depth, Overwrite

Comportement : Les verrous ne sont PAS copiés.

9.9 Méthode MOVE​

MOVE est logiquement équivalent à COPY + DELETE.

Atomicité : Les opérations MOVE doivent (MUST) être atomiques.

9.10 Méthode LOCK​

LOCK obtient un verrou sur une ressource.

Types de verrous : Verrou d'écriture exclusif, Verrou d'écriture partagé

9.11 Méthode UNLOCK​

UNLOCK supprime le verrou identifié par le jeton de verrou.

Pour les spécifications complètes des méthodes, consultez RFC 4918 Sections 9.1-9.11.

10. En-têtes HTTP pour la création distribuée (HTTP Headers for Distributed Authoring)​

WebDAV (Web Distributed Authoring and Versioning, création et gestion de versions distribuées sur le Web) définit plusieurs nouveaux en-têtes HTTP pour prendre en charge les fonctionnalités de création distribuée.

10.1 En-tête DAV (DAV Header)​

L'en-tête DAV indique le niveau de fonctionnalités WebDAV pris en charge par le serveur.

Syntaxe​

DAV: 1, 2, 3, access-control, calendar-access

Niveaux de conformité​

  • 1 : prise en charge WebDAV de base (PROPFIND, PROPPATCH, MKCOL, extensions GET/HEAD, extensions PUT, extensions DELETE, OPTIONS, COPY, MOVE)
  • 2 : inclut le niveau 1 + prise en charge de LOCK et UNLOCK
  • 3 : inclut le niveau 2 + prise en charge des collections ordonnées (optionnel)

Cas d'utilisation​

Réponse OPTIONS :

OPTIONS /resource HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
DAV: 1, 2
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK

10.2 En-tête Depth (Depth Header)​

L'en-tête Depth est utilisé pour spécifier la profondeur à laquelle une opération DOIT s'appliquer dans la hiérarchie de ressources.

Syntaxe​

Depth: 0 | 1 | infinity

Signification des valeurs​

  • 0 : s'applique uniquement à la ressource cible elle-même
  • 1 : s'applique à la ressource et à ses membres directs
  • infinity : s'applique récursivement à la ressource et à tous ses descendants

Méthodes applicables​

MéthodePrise en charge de DepthValeur par défaut
PROPFIND0, 1, infinityinfinity
COPY0, infinityinfinity
MOVEinfinity (les autres valeurs sont ignorées)infinity
LOCK0, infinityinfinity
DELETEignoré (toujours récursif)N/A

Exemple​

<!-- Interroger uniquement les propriétés de la collection elle-même -->
PROPFIND /collection/ HTTP/1.1
Host: example.com
Depth: 0

<!-- Interroger la collection et ses membres directs -->
PROPFIND /collection/ HTTP/1.1
Host: example.com
Depth: 1

10.3 En-tête Destination (Destination Header)​

L'en-tête Destination spécifie l'URL de destination pour les opérations COPY ou MOVE.

Syntaxe​

Destination: absoluteURI

Exigences​

  • Obligatoire : les méthodes COPY et MOVE DOIVENT inclure cet en-tête
  • URI absolu : DOIT être un URI absolu complet
  • Même serveur : la source et la destination sont généralement requises sur le même serveur

Exemple​

COPY /source/file.txt HTTP/1.1
Host: example.com
Destination: http://example.com/destination/file.txt
Overwrite: T

MOVE /old-name.doc HTTP/1.1
Host: example.com
Destination: http://example.com/new-name.doc

10.4 En-tête If (If Header)​

L'en-tête If fournit un mécanisme pour conditionner l'exécution des méthodes WebDAV, utilisé pour soumettre des jetons de verrou et des ETags.

Syntaxe​

L'en-tête If a deux formes :

Forme No-tag-list :

If: (&lt;locktoken>) ([etag])

Forme Tagged-list :

If: &lt;resource-url> (&lt;locktoken>)

Usages​

  1. Soumettre un jeton de verrou — prouver que le client détient le verrou
  2. Requête conditionnelle — exécution conditionnelle basée sur l'ETag
  3. Combinaison logique — prend en charge la logique ET et OU

Exemple​

Soumettre un jeton de verrou :

PUT /locked-resource HTTP/1.1
Host: example.com
If: (&lt;urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
Content-Type: text/plain

Updated content

Conditions multiples :

DELETE /resource HTTP/1.1
Host: example.com
If: `http://example.com/resource` 
    (&lt;urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
    (["e0-b2-1a2"])

Condition NOT :

If: (Not &lt;urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)

Règles de correspondance de l'en-tête If​

  1. Correspondance du jeton de verrou — vérifier si le jeton soumis correspond au verrou de la ressource
  2. Correspondance ETag — vérifier si l'étiquette d'entité correspond
  3. Évaluation logique — évaluation de gauche à droite, avec court-circuit

Cas d'utilisation​

Cas 1 : Modifier une ressource verrouillée

PUT /locked-doc HTTP/1.1
If: (&lt;urn:uuid:lock-token-here>)

Cas 2 : COPY vers une destination verrouillée

COPY /source HTTP/1.1
Destination: http://example.com/locked-dest
If: `http://example.com/locked-dest` 
    (&lt;urn:uuid:dest-lock-token>)

Cas 3 : Mise à jour conditionnelle

PUT /resource HTTP/1.1
If: (["etag-value"])

10.5 En-tête Lock-Token (Lock-Token Header)​

L'en-tête Lock-Token est utilisé dans la méthode UNLOCK pour spécifier le verrou à supprimer.

Syntaxe​

Lock-Token: &lt;uri>

Utilisation​

Utilisé uniquement pour UNLOCK :

UNLOCK /resource HTTP/1.1
Host: example.com
Lock-Token: &lt;urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>

HTTP/1.1 204 No Content

Différence avec l'en-tête If​

  • Lock-Token : utilisé uniquement pour UNLOCK, spécifie le verrou à supprimer
  • If : utilisé pour les autres méthodes, soumet le jeton de verrou pour prouver l'autorisation

10.6 En-tête Overwrite (Overwrite Header)​

L'en-tête Overwrite spécifie si une opération COPY ou MOVE DOIT écraser la ressource de destination.

Syntaxe​

Overwrite: T | F

Valeurs​

  • T (True) : écraser la ressource de destination (par défaut)
  • F (False) : ne pas écraser ; échouer si la destination existe

Comportement​

Overwrite: T :

  • Si la destination existe, la supprimer d'abord
  • Puis créer la nouvelle ressource
  • Retourner 204 No Content

Overwrite: F :

  • Si la destination existe, l'opération échoue
  • Retourner 412 Precondition Failed
  • Aucune ressource n'est modifiée

Exemple​

<!-- Ne pas écraser le fichier existant -->
COPY /source.txt HTTP/1.1
Host: example.com
Destination: http://example.com/dest.txt
Overwrite: F

<!-- Si dest.txt existe -->
HTTP/1.1 412 Precondition Failed

<!-- Si dest.txt n'existe pas -->
HTTP/1.1 201 Created

10.7 En-tête Timeout de requête (Timeout Request Header)​

L'en-tête Timeout est utilisé dans les requêtes LOCK pour suggérer un délai d'expiration du verrou.

Syntaxe​

Timeout: Second-&lt;seconds> | Infinite

Exemple​

LOCK /resource HTTP/1.1
Host: example.com
Timeout: Second-3600

<!-- Ou demander un délai d'expiration infini -->
Timeout: Infinite

<!-- Plusieurs valeurs de délai (par ordre de priorité) -->
Timeout: Infinite, Second-604800, Second-86400

Comportement du serveur​

  • PEUT refuser : le serveur PEUT ignorer la suggestion du client
  • Retourner la valeur réelle : la réponse DOIT inclure le délai d'expiration choisi par le serveur
  • Limites de sécurité : le serveur PEUT limiter le délai d'expiration maximal

Timeout dans la réponse​

&lt;D:activelock>
  &lt;D:timeout>Second-3600&lt;D:timeout>
  ...
&lt;D:activelock>

Référence rapide des en-têtes HTTP​

En-têteMéthodesObligatoire/OptionnelDescription
DAVOPTIONSRéponseNiveaux de fonctionnalités pris en charge par le serveur
DepthPROPFIND, COPY, LOCKOptionnelProfondeur de l'opération
DestinationCOPY, MOVEObligatoireURL de destination
IfToutes méthodesOptionnelExécution conditionnelle et soumission de jeton de verrou
Lock-TokenUNLOCKObligatoireJeton de verrou à supprimer
OverwriteCOPY, MOVEOptionnelÉcraser ou non la destination
TimeoutLOCKOptionnelDélai d'expiration suggéré du verrou

Résumé du chapitre : Le chapitre 10 définit les 7 en-têtes HTTP spécialisés de WebDAV. Ces en-têtes étendent les capacités d'HTTP/1.1 pour prendre en charge les opérations en profondeur (Depth), les opérations sur les ressources (Destination, Overwrite), la gestion des verrous (Lock-Token, Timeout) et l'exécution conditionnelle (If). L'utilisation correcte de ces en-têtes est essentielle pour implémenter des clients et serveurs WebDAV fiables.

12. Use of HTTP Status Codes (Utilisation des codes d'état HTTP)​

Ces codes HTTP ne sont pas redéfinis, mais leur utilisation est quelque peu étendue par les méthodes et les exigences WebDAV. En général, de nombreux codes d'état HTTP peuvent être utilisés en réponse à toute demande, et pas seulement dans les cas décrits dans ce document. Notez également que les serveurs WebDAV sont connus pour utiliser des réponses de redirection de niveau 300 (et les premiers tests d'interopérabilité ont révélé que les clients n'étaient pas préparés à voir ces réponses). Une réponse de niveau 300 NE DOIT PAS être utilisée lorsque le serveur a créé une nouvelle ressource en réponse à la demande.

12.1. 412 Precondition Failed (412 Échec de la précondition)​

Toute demande peut contenir un en-tête conditionnel défini dans HTTP (If-Match, If-Modified-Since, etc.) ou les en-têtes conditionnels "If" ou "Overwrite" définis dans cette spécification. Si le serveur évalue un en-tête conditionnel et que cette condition n'est pas remplie, alors ce code d'erreur DOIT être retourné. D'autre part, si le client n'a pas inclus d'en-tête conditionnel dans la demande, alors le serveur NE DOIT PAS utiliser ce code d'état.

12.2. 414 Request-URI Too Long (414 URI de demande trop long)​

Ce code d'état est utilisé dans HTTP 1.1 uniquement pour les Request-URI, pas pour les URI dans d'autres emplacements.

13. Multi-Status Response (Réponse multi-états)​

Une réponse Multi-Status transmet des informations sur plusieurs ressources dans des situations où plusieurs codes d'état pourraient être appropriés. Le corps de réponse Multi-Status par défaut est une entité HTTP text/xml ou application/xml avec un élément racine 'multistatus'. D'autres éléments contiennent des codes d'état des séries 200, 300, 400 et 500 générés lors de l'invocation de la méthode. Les codes d'état de la série 100 NE DEVRAIENT PAS être enregistrés dans un élément XML 'response'.

Bien que '207' soit utilisé comme code d'état de réponse global, le destinataire doit consulter le contenu du corps de réponse multistatus pour obtenir des informations supplémentaires sur le succès ou l'échec de l'exécution de la méthode. La réponse PEUT être utilisée dans des situations de succès, de succès partiel et aussi d'échec.

L'élément racine 'multistatus' contient zéro ou plusieurs éléments 'response' dans n'importe quel ordre, chacun avec des informations sur une ressource individuelle. Chaque élément 'response' DOIT avoir un élément 'href' pour identifier la ressource.

Une réponse Multi-Status utilise l'un des deux formats distincts pour représenter l'état:

  1. Un élément 'status' en tant qu'enfant de l'élément 'response' indique l'état de l'exécution du message pour la ressource identifiée dans son ensemble (par exemple, voir la section 9.6.2). Certaines définitions de méthodes fournissent des informations sur les codes d'état spécifiques que les clients devraient être préparés à voir dans une réponse. Cependant, les clients DOIVENT être capables de gérer d'autres codes d'état, en utilisant les règles génériques définies dans la section 10 de [RFC2616].

  2. Pour PROPFIND et PROPPATCH, le format a été étendu en utilisant l'élément 'propstat' au lieu de 'status', fournissant des informations sur les propriétés individuelles d'une ressource. Ce format est spécifique à PROPFIND et PROPPATCH, et est décrit en détail dans les sections 9.1 et 9.2.

13.1. Response Headers (En-têtes de réponse)​

HTTP définit l'en-tête Location pour indiquer une URL préférée pour la ressource qui a été adressée dans le Request-URI (par exemple, en réponse à des requêtes PUT réussies ou dans des réponses de redirection). Cependant, l'utilisation de cet en-tête crée une ambiguïté lorsqu'il y a des URL dans le corps de la réponse, comme avec Multi-Status. Ainsi, l'utilisation de l'en-tête Location avec la réponse Multi-Status est intentionnellement non définie.

13.2. Handling Redirected Child Resources (Gestion des ressources enfants redirigées)​

Les réponses de redirection (300-303, 305 et 307) définies dans HTTP 1.1 prennent normalement un en-tête Location pour indiquer le nouvel URI pour la ressource unique redirigée depuis le Request-URI. Les réponses Multi-Status contiennent de nombreuses adresses de ressources, mais la définition originale dans [RFC2518] n'avait aucun endroit pour que le serveur fournisse le nouvel URI pour les ressources redirigées. Cette spécification définit un élément 'location' pour cette information (voir la section 14.9). Les serveurs DOIVENT utiliser ce nouvel élément avec les réponses de redirection dans Multi-Status.

Les clients rencontrant des ressources redirigées dans Multi-Status NE DOIVENT PAS compter sur la présence de l'élément 'location' avec un nouvel URI. Si l'élément n'est pas présent, le client PEUT réémettre la requête vers la ressource redirigée individuelle, car la réponse à cette requête peut être redirigée avec un en-tête Location contenant le nouvel URI.

13.3. Internal Status Codes (Codes d'état internes)​

Les sections 9.2.1, 9.1.2, 9.6.1, 9.8.3 et 9.9.2 définissent divers codes d'état utilisés dans les réponses Multi-Status. Cette spécification ne définit pas la signification des autres codes d'état qui pourraient apparaître dans ces réponses.

16. Precondition/Postcondition XML Elements (Éléments XML de précondition/postcondition)​

Comme introduit dans la section 8.7, des informations supplémentaires sur les conditions d'erreur peuvent être incluses dans le corps de nombreuses réponses d'état. Cette section formule des exigences sur l'utilisation du mécanisme de corps d'erreur et introduit un certain nombre de codes de précondition et de postcondition.

Une "précondition" d'une méthode décrit l'état du serveur qui doit être vrai pour que cette méthode soit exécutée. Une "postcondition" d'une méthode décrit l'état du serveur qui doit être vrai après que cette méthode ait été complétée.

Chaque précondition et postcondition a un élément XML unique qui lui est associé. Dans une réponse 207 Multi-Status, l'élément XML DOIT apparaître à l'intérieur d'un élément 'error' dans l'élément 'propstat ou 'response' approprié selon que la condition s'applique à une ou plusieurs propriétés ou à la ressource dans son ensemble. Dans toutes les autres réponses d'erreur où le corps 'error' de cette spécification est utilisé, l'élément XML de précondition/postcondition DOIT être retourné en tant qu'enfant d'un élément 'error' de niveau supérieur dans le corps de la réponse, sauf négociation contraire par la requête, avec un état de réponse approprié. Les codes d'état de réponse les plus courants sont 403 (Forbidden) si la requête ne doit pas être répétée car elle échouera toujours, et 409 (Conflict) s'il est prévu que l'utilisateur puisse résoudre le conflit et soumettre à nouveau la requête. L'élément 'error' PEUT contenir des éléments enfants avec des informations d'erreur spécifiques et PEUT être étendu avec n'importe quels éléments enfants personnalisés.

Ce mécanisme ne remplace pas l'utilisation d'un code d'état numérique correct tel que défini ici ou dans HTTP, car le client doit toujours être capable de prendre une ligne de conduite raisonnable basée uniquement sur le code numérique. Cependant, cela élimine le besoin de définir de nouveaux codes numériques. Les nouveaux codes lisibles par machine utilisés à cette fin sont des éléments XML classés comme préconditions et postconditions, donc naturellement, tout groupe définissant un nouveau code de condition peut utiliser son propre espace de noms. Comme toujours, l'espace de noms "DAV:" est réservé à l'usage des groupes de travail WebDAV agréés par l'IETF.

Un serveur prenant en charge cette spécification DEVRAIT utiliser l'erreur XML chaque fois qu'une précondition ou postcondition définie dans ce document est violée. Pour les conditions d'erreur non spécifiées dans ce document, le serveur PEUT simplement choisir un état numérique approprié et laisser le corps de la réponse vide. Cependant, un serveur PEUT plutôt utiliser un code de condition personnalisé et d'autres textes de support, car même lorsque les clients ne reconnaissent pas automatiquement les codes de condition, ils peuvent être très utiles dans les tests d'interopérabilité et le débogage.

Exemple - Réponse avec code de précondition:

HTTP/1.1 423 Locked
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:error xmlns:D="DAV:">
  &lt;D:lock-token-submitted>
    &lt;D:href>/workspace/webdav/&lt;D:href>
  &lt;D:lock-token-submitted>
&lt;D:error>

Dans cet exemple, un client ignorant un verrou de profondeur infinie sur la collection parente "/workspace/webdav/" a tenté de modifier le membre de la collection "/workspace/webdav/proposal.doc".

D'autres préconditions et postconditions utiles ont été définies dans d'autres spécifications étendant WebDAV, telles que [RFC3744] (voir en particulier la section 7.1.1), [RFC3253] et [RFC3648].

Tous ces éléments sont dans l'espace de noms "DAV:". Sauf indication contraire, le contenu de l'élément XML de chaque condition est défini comme étant vide.

lock-token-matches-request-uri​

Nom (Name): lock-token-matches-request-uri

Utiliser avec (Use with): 409 Conflict

Objectif (Purpose): (précondition) -- Une requête peut inclure un en-tête Lock-Token pour identifier un verrou pour la méthode UNLOCK. Cependant, si le Request-URI ne tombe pas dans la portée du verrou identifié par le jeton, le serveur DEVRAIT utiliser cette erreur. Le verrou peut avoir une portée qui n'inclut pas le Request-URI, ou le verrou peut avoir disparu, ou le jeton peut être invalide.

lock-token-submitted​

Nom (Name): lock-token-submitted (précondition)

Utiliser avec (Use with): 423 Locked

Objectif (Purpose): La requête n'a pas pu réussir car un jeton de verrou aurait dû être soumis. Cet élément, s'il est présent, DOIT contenir au moins une URL d'une ressource verrouillée qui a empêché la requête. Dans les cas de MOVE, COPY et DELETE où des verrous de collection sont impliqués, il peut être difficile pour le client de découvrir quelle ressource verrouillée a fait échouer la requête -- mais le serveur est seulement responsable de retourner une telle ressource verrouillée. Le serveur PEUT retourner toutes les ressources verrouillées qui ont empêché la requête de réussir s'il les connaît toutes.

&lt;!ELEMENT lock-token-submitted (href+) >

no-conflicting-lock​

Nom (Name): no-conflicting-lock (précondition)

Utiliser avec (Use with): Généralement 423 Locked

Objectif (Purpose): Une requête LOCK a échoué en raison de la présence d'un verrou conflictuel déjà existant. Notez qu'un verrou peut être en conflit bien que la ressource vers laquelle la requête a été dirigée ne soit que indirectement verrouillée. Dans ce cas, le code de précondition peut être utilisé pour informer le client de la ressource qui est la racine du verrou conflictuel, évitant une recherche séparée de la propriété "lockdiscovery".

&lt;!ELEMENT no-conflicting-lock (href)* >

no-external-entities​

Nom (Name): no-external-entities

Utiliser avec (Use with): 403 Forbidden

Objectif (Purpose): (précondition) -- Si le serveur rejette une requête client parce que le corps de la requête contient une entité externe, le serveur DEVRAIT utiliser cette erreur.

preserved-live-properties​

Nom (Name): preserved-live-properties

Utiliser avec (Use with): 409 Conflict

Objectif (Purpose): (postcondition) -- Le serveur a reçu une requête MOVE ou COPY par ailleurs valide, mais ne peut pas maintenir les propriétés dynamiques avec le même comportement à la destination. Il se peut que le serveur ne prenne en charge certaines propriétés dynamiques que dans certaines parties du référentiel, ou qu'il ait simplement une erreur interne.

propfind-finite-depth​

Nom (Name): propfind-finite-depth

Utiliser avec (Use with): 403 Forbidden

Objectif (Purpose): (précondition) -- Ce serveur n'autorise pas les requêtes PROPFIND de profondeur infinie sur les collections.

cannot-modify-protected-property​

Nom (Name): cannot-modify-protected-property

Utiliser avec (Use with): 403 Forbidden

Objectif (Purpose): (précondition) -- Le client a tenté de définir une propriété protégée dans un PROPPATCH (comme DAV:getetag). Voir également [RFC3253], Section 3.12.

17. XML Extensibility in DAV (Extensibilité XML dans DAV)​

L'extension d'espace de noms XML ([REC-XML-NAMES]) est utilisée dans cette spécification afin de permettre l'ajout de nouveaux éléments XML sans crainte de collision avec d'autres noms d'éléments. Bien que les corps de requête et de réponse WebDAV puissent être étendus par des éléments XML arbitraires, qui peuvent être ignorés par le destinataire du message, un élément XML dans l'espace de noms "DAV:" NE DEVRAIT PAS être utilisé dans le corps de la requête ou de la réponse à moins que cet élément XML ne soit explicitement défini dans un RFC IETF révisé par un groupe de travail WebDAV.

Pour que WebDAV soit à la fois extensible et rétrocompatible, les clients et les serveurs doivent savoir comment se comporter lorsque des extensions de commande inattendues ou non reconnues sont reçues. Pour le traitement XML, cela signifie que les clients et les serveurs DOIVENT traiter les documents XML reçus comme si les éléments et attributs inattendus (et tous les enfants d'éléments non reconnus) n'étaient pas là. Un élément ou attribut inattendu inclut celui qui peut être utilisé dans un autre contexte mais n'est pas attendu ici. Ignorer ces éléments aux fins du traitement peut bien sûr être cohérent avec la journalisation de toutes les informations ou la présentation pour le débogage.

Cette restriction s'applique également au traitement, par les clients, des valeurs de propriété DAV où les éléments XML inattendus DEVRAIENT être ignorés sauf si le schéma de la propriété déclare le contraire.

Cette restriction ne s'applique pas à la définition de propriétés DAV mortes sur le serveur où le serveur DOIT enregistrer tous les éléments XML.

De plus, cette restriction ne s'applique pas à l'utilisation de XML où XML se trouve être le type de contenu du corps d'entité, par exemple, lorsqu'il est utilisé comme corps d'un PUT.

Les instructions de traitement en XML DEVRAIENT être ignorées par les destinataires. Ainsi, les spécifications étendant WebDAV NE DEVRAIENT PAS utiliser d'instructions de traitement pour définir un comportement normatif.

Des fragments de DTD XML sont inclus pour tous les éléments XML définis dans cette spécification. Cependant, le XML correct ne sera pas valide selon une DTD en raison de l'utilisation de l'espace de noms et des règles d'extension. En particulier:

  • Les éléments (de cette spécification) sont dans l'espace de noms "DAV:",
  • L'ordre des éléments n'est pas pertinent sauf indication contraire,
  • Les attributs d'extension PEUVENT être ajoutés,
  • Pour les définitions de type d'élément "ANY", la définition de texte normatif pour cet élément définit ce qui peut y être et ce que cela signifie.
  • Pour les définitions de type d'élément "#PCDATA", les éléments d'extension NE DOIVENT PAS être ajoutés.
  • Pour les autres définitions de type d'élément, y compris "EMPTY", les éléments d'extension PEUVENT être ajoutés.

Notez que cela signifie que les éléments contenant des éléments ne peuvent pas être étendus pour contenir du texte, et vice versa.

Avec la validation DTD assouplie par les règles ci-dessus, les contraintes décrites par les fragments DTD sont normatives (voir par exemple l'annexe A). Un destinataire d'un message WebDAV avec un corps XML NE DOIT PAS valider le document XML selon une DTD codée en dur ou déclarée dynamiquement.

Notez que cette section décrit des règles d'extensibilité rétrocompatibles. Il peut également y avoir des moments où une extension est conçue pour ne pas être rétrocompatible, par exemple, en définissant une extension qui réutilise un élément XML défini dans ce document mais omet l'un des éléments enfants requis par les DTD de cette spécification.

18. DAV Compliance Classes (Classes de conformité DAV)​

Une ressource conforme à DAV peut annoncer plusieurs classes de conformité. Un client peut découvrir les classes de conformité d'une ressource en exécutant OPTIONS sur la ressource et en examinant l'en-tête "DAV" qui est retourné. Notez en particulier que ce sont les ressources, plutôt que les serveurs, dont on parle comme étant conformes. C'est parce que théoriquement certaines ressources sur un serveur pourraient prendre en charge différents ensembles de fonctionnalités. Par exemple, un serveur pourrait avoir un sous-référentiel où une fonctionnalité avancée comme le versioning est prise en charge, même si cette fonctionnalité n'est pas prise en charge sur tous les sous-référentiels.

Étant donné que ce document décrit des extensions au protocole HTTP/1.1, au minimum toutes les ressources, clients et proxies conformes à DAV DOIVENT être conformes à [RFC2616].

Une ressource conforme à la classe 2 ou à la classe 3 doit également être conforme à la classe 1.

18.1. Class 1 (Classe 1)​

Une ressource conforme à la classe 1 DOIT répondre à toutes les exigences "DOIT" dans toutes les sections de ce document.

Les ressources conformes à la classe 1 DOIVENT retourner, au minimum, la valeur "1" dans l'en-tête DAV sur toutes les réponses à la méthode OPTIONS.

18.2. Class 2 (Classe 2)​

Une ressource conforme à la classe 2 DOIT répondre à toutes les exigences de la classe 1 et prendre en charge la méthode LOCK, la propriété DAV:supportedlock, la propriété DAV:lockdiscovery, l'en-tête de réponse Time-Out et l'en-tête de requête Lock-Token. Une ressource conforme à la classe 2 DEVRAIT également prendre en charge l'en-tête de requête Timeout et l'élément XML 'owner'.

Les ressources conformes à la classe 2 DOIVENT retourner, au minimum, les valeurs "1" et "2" dans l'en-tête DAV sur toutes les réponses à la méthode OPTIONS.

18.3. Class 3 (Classe 3)​

Une ressource peut explicitement annoncer son support pour les révisions apportées à [RFC2518] dans ce document. La classe 1 DOIT également être prise en charge. La classe 2 PEUT être prise en charge. Annoncer le support de la classe 3 en plus des classes 1 et 2 signifie que le serveur prend en charge toutes les exigences de cette spécification. Annoncer le support des classes 3 et 1, mais pas de la classe 2, signifie que le serveur prend en charge toutes les exigences de cette spécification, sauf éventuellement celles qui impliquent le support des verrous.

Exemple:

DAV: 1, 3

19. Internationalization Considerations (Considérations d'internationalisation)​

Dans le domaine de l'internationalisation, cette spécification est conforme à la politique de jeu de caractères de l'IETF [RFC2277]. Dans cette spécification, les champs lisibles par l'homme peuvent être trouvés soit dans la valeur d'une propriété, soit dans un message d'erreur renvoyé dans le corps d'une entité de réponse. Dans les deux cas, le contenu lisible par l'homme est encodé en XML, qui dispose de dispositions explicites pour le balisage et l'encodage des jeux de caractères, et exige que les processeurs XML lisent les éléments XML encodés, au minimum, en utilisant les encodages UTF-8 [RFC3629] et UTF-16 [RFC2781] du plan multilingue ISO 10646. Les exemples XML de cette spécification démontrent l'utilisation du paramètre charset de l'en-tête Content-Type (défini dans [RFC3023]), ainsi que les déclarations de charset XML.

XML fournit également une capacité de balisage de langue pour spécifier la langue du contenu d'un élément XML particulier. L'attribut "xml:lang" apparaît sur un élément XML pour identifier la langue de son contenu et de ses attributs. Voir [REC-XML] pour les définitions des valeurs et de la portée.

Les applications WebDAV DOIVENT prendre en charge le balisage des jeux de caractères, l'encodage des jeux de caractères et la fonctionnalité de balisage de langue de la spécification XML. Les implémenteurs d'applications WebDAV sont fortement encouragés à lire "XML Media Types" [RFC3023] pour obtenir des instructions sur le type de média MIME à utiliser pour le transport XML et sur l'utilisation du paramètre charset de l'en-tête Content-Type.

Les noms utilisés dans cette spécification se répartissent en quatre catégories: les noms d'éléments de protocole tels que les méthodes et les en-têtes, les noms d'éléments XML, les noms de propriétés et les noms de conditions. La dénomination des éléments de protocole suit le précédent de HTTP, en utilisant des noms anglais encodés en US-ASCII pour les méthodes et les en-têtes. Étant donné que ces éléments de protocole ne sont pas visibles pour les utilisateurs et ne sont que de longs identifiants de jeton, ils n'ont pas besoin de prendre en charge plusieurs langues. De même, les noms des éléments XML utilisés dans cette spécification ne sont pas visibles pour l'utilisateur et n'ont donc pas besoin de prendre en charge plusieurs langues.

Les noms de propriétés WebDAV sont des noms XML qualifiés (paires de nom d'espace de noms XML et de nom local). Bien que certaines applications (par exemple, un visualiseur de propriétés générique) affichent directement les noms de propriétés à leurs utilisateurs, on s'attend à ce que l'application typique utilise un ensemble fixe de propriétés et fournisse un mappage du nom de propriété et de l'espace de noms vers un champ lisible par l'homme lors de l'affichage du nom de propriété à un utilisateur. Ce n'est que dans le cas où l'ensemble de propriétés n'est pas connu à l'avance qu'une application doit afficher un nom de propriété à un utilisateur. Nous recommandons que les applications fournissent des noms de propriétés lisibles par l'homme chaque fois que cela est possible.

Pour le rapport d'erreurs, nous suivons la convention des codes d'état HTTP/1.1, en incluant avec chaque code d'état une courte description en anglais du code (par exemple, 423 (Locked)). Bien qu'il existe une possibilité qu'un agent utilisateur mal conçu affiche ce message à un utilisateur, les applications internationalisées ignoreront ce message et afficheront un message approprié dans la langue et le jeu de caractères de l'utilisateur.

Étant donné que l'interopération des clients et des serveurs ne nécessite pas d'informations de paramètres régionaux, cette spécification ne spécifie aucun mécanisme pour la transmission de ces informations.

20. Security Considerations (Considérations de sécurité)​

Cette section est fournie pour détailler les questions concernant les implications de sécurité dont les applications WebDAV doivent être conscientes.

Toutes les considérations de sécurité de HTTP/1.1 (discutées dans [RFC2616]) et XML (discutées dans [RFC3023]) s'appliquent également à WebDAV. De plus, les risques de sécurité inhérents à la création à distance nécessitent une technologie d'authentification plus forte, introduisent plusieurs nouvelles préoccupations en matière de confidentialité et peuvent augmenter les dangers d'une mauvaise conception de serveur. Ces questions sont détaillées ci-dessous.

20.1. Authentication of Clients (Authentification des clients)​

En raison de leur accent sur la création, les serveurs WebDAV doivent utiliser une technologie d'authentification pour protéger non seulement l'accès à une ressource réseau, mais aussi l'intégrité de la ressource. De plus, l'introduction de la fonctionnalité de verrouillage nécessite un support pour l'authentification.

Un mot de passe envoyé en clair sur un canal non sécurisé est un moyen inadéquat pour protéger l'accessibilité et l'intégrité d'une ressource car le mot de passe peut être intercepté. Étant donné que l'authentification de base pour HTTP/1.1 effectue essentiellement une transmission en texte clair d'un mot de passe, l'authentification de base NE DOIT PAS être utilisée pour authentifier un client WebDAV auprès d'un serveur à moins que la connexion ne soit sécurisée. De plus, un serveur WebDAV NE DOIT PAS envoyer un défi d'authentification de base dans un en-tête WWW-Authenticate à moins que la connexion ne soit sécurisée. Un exemple de connexion sécurisée serait une connexion Transport Layer Security (TLS) employant une suite de chiffrement forte et une authentification de serveur.

Les applications WebDAV DOIVENT prendre en charge le schéma d'authentification Digest [RFC2617]. Étant donné que l'authentification Digest vérifie que les deux parties d'une communication connaissent un secret partagé, un mot de passe, sans avoir à envoyer ce secret en clair, l'authentification Digest évite les problèmes de sécurité inhérents à l'authentification de base tout en fournissant un niveau d'authentification utile dans un large éventail de scénarios.

20.2. Denial of Service (Déni de service)​

Les attaques par déni de service sont particulièrement préoccupantes pour les serveurs WebDAV. WebDAV plus HTTP permet des attaques par déni de service sur chaque partie des ressources d'un système.

  • Le stockage sous-jacent peut être attaqué en effectuant un PUT de fichiers extrêmement volumineux.
  • Demander des opérations récursives sur de grandes collections peut attaquer le temps de traitement.
  • Effectuer plusieurs demandes en pipeline sur plusieurs connexions peut attaquer les connexions réseau.

Les serveurs WebDAV doivent être conscients de la possibilité d'une attaque par déni de service à tous les niveaux. La réponse appropriée à une telle attaque PEUT être de simplement abandonner la connexion. Ou, si le serveur est capable de faire une réponse, le serveur PEUT utiliser une demande de statut de niveau 400 telle que 400 (Bad Request) et indiquer pourquoi la demande a été refusée (une réponse de statut de niveau 500 indiquerait que le problème vient du serveur, alors que les attaques DoS involontaires sont quelque chose que le client est capable de remédier).

20.3. Security through Obscurity (Sécurité par l'obscurité)​

WebDAV fournit, via la méthode PROPFIND, un mécanisme pour lister les ressources membres d'une collection. Cela diminue considérablement l'efficacité des techniques de sécurité ou de confidentialité qui reposent uniquement sur la difficulté de découvrir les noms des ressources réseau. Les utilisateurs de serveurs WebDAV sont encouragés à utiliser des techniques de contrôle d'accès pour empêcher l'accès non désiré aux ressources, plutôt que de dépendre de l'obscurité relative de leurs noms de ressources.

20.4. Privacy Issues Connected to Locks (Problèmes de confidentialité liés aux verrous)​

Lors de la soumission d'une demande de verrouillage, un agent utilisateur peut également soumettre un champ XML 'owner' donnant des informations de contact pour la personne prenant le verrou (pour les cas où une personne, plutôt qu'un robot, prend le verrou). Ces informations de contact sont stockées dans une propriété DAV:lockdiscovery sur la ressource et peuvent être utilisées par d'autres collaborateurs pour commencer une négociation sur l'accès à la ressource. Cependant, dans de nombreux cas, ces informations de contact peuvent être très privées et ne doivent pas être largement diffusées. Les serveurs DEVRAIENT limiter l'accès en lecture à la propriété DAV:lockdiscovery de manière appropriée. De plus, les agents utilisateurs DEVRAIENT fournir un contrôle sur l'envoi ou non d'informations de contact, et si des informations de contact sont envoyées, un contrôle sur exactement quelles informations sont envoyées.

20.5. Privacy Issues Connected to Properties (Problèmes de confidentialité liés aux propriétés)​

Étant donné que les valeurs de propriété sont généralement utilisées pour contenir des informations telles que l'auteur d'un document, il existe la possibilité que des préoccupations en matière de confidentialité puissent survenir en raison d'un accès généralisé aux données de propriété d'une ressource. Pour réduire le risque de divulgation involontaire d'informations privées via les propriétés, les serveurs sont encouragés à développer des mécanismes de contrôle d'accès qui séparent l'accès en lecture au corps de la ressource et l'accès en lecture aux propriétés de la ressource. Cela permet à un utilisateur de contrôler la diffusion de ses données de propriété sans restreindre excessivement l'accès au contenu de la ressource.

20.6. Implications of XML Entities (Implications des entités XML)​

XML prend en charge une fonctionnalité connue sous le nom d'"entités externes", définie dans la section 4.2.2 de [REC-XML], qui demande à un processeur XML de récupérer et d'inclure du XML supplémentaire. Une entité XML externe peut être utilisée pour ajouter ou modifier la déclaration de type de document (DTD) associée à un document XML. Une entité XML externe peut également être utilisée pour inclure du XML dans le contenu d'un document XML. Pour le XML non validant, tel que le XML utilisé dans cette spécification, inclure une entité XML externe n'est pas requis par XML. Cependant, XML déclare qu'un processeur XML peut, à sa discrétion, inclure l'entité XML externe.

Les entités XML externes n'ont aucune fiabilité inhérente et sont soumises à toutes les attaques endémiques à toute demande HTTP GET. De plus, il est possible pour une entité XML externe de modifier la DTD et donc d'affecter la forme finale d'un document XML, dans le pire des cas, en modifiant considérablement sa sémantique ou en exposant le processeur XML aux risques de sécurité discutés dans [RFC3023]. Par conséquent, les implémenteurs doivent être conscients que les entités XML externes doivent être traitées comme non fiables. Si un serveur choisit de ne pas gérer les entités XML externes, il DEVRAIT répondre aux demandes contenant des entités externes avec le code de condition 'no-external-entities'.

Il existe également un risque d'évolutivité qui accompagnerait une application largement déployée qui utiliserait des entités XML externes. Dans cette situation, il est possible qu'il y ait un nombre important de demandes pour une entité XML externe, surchargeant potentiellement tout serveur qui traite les demandes pour la ressource contenant l'entité XML externe.

De plus, il existe également un risque basé sur l'évaluation des "entités internes" telles que définies dans la section 4.2.2 de [REC-XML]. Une petite demande soigneusement élaborée utilisant des entités internes imbriquées peut nécessiter d'énormes quantités de mémoire et/ou de temps de traitement pour être traitée. Les implémenteurs de serveurs doivent être conscients de ce risque et configurer leurs analyseurs XML afin que des demandes comme celles-ci puissent être détectées et rejetées le plus tôt possible.

20.7. Risks Connected with Lock Tokens (Risques liés aux jetons de verrouillage)​

Cette spécification encourage l'utilisation de "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]) pour les jetons de verrouillage (section 6.5), afin de garantir leur unicité dans l'espace et le temps. Les UUID de version 1 (définis dans la section 4) PEUVENT contenir un champ "node" qui "se compose d'une adresse MAC IEEE 802, généralement l'adresse de l'hôte. Pour les systèmes avec plusieurs adresses IEEE, n'importe laquelle disponible peut être utilisée". Étant donné qu'un serveur WebDAV émettra de nombreux verrous au cours de sa durée de vie, l'implication est qu'il peut également exposer publiquement son adresse IEEE 802.

Plusieurs risques sont associés à l'exposition des adresses IEEE 802. En utilisant l'adresse IEEE 802:

  • Il est possible de suivre le déplacement du matériel de sous-réseau en sous-réseau.
  • Il peut être possible d'identifier le fabricant du matériel exécutant un serveur WebDAV.
  • Il peut être possible de déterminer le nombre de chaque type d'ordinateur exécutant WebDAV.

Ce risque ne s'applique qu'aux versions UUID basées sur l'adresse de l'hôte. La section 4 de [RFC4122] décrit plusieurs autres mécanismes pour générer des UUID qui n'impliquent pas l'adresse de l'hôte et ne souffrent donc pas de ce risque.

20.8. Hosting Malicious Content (Hébergement de contenu malveillant)​

HTTP a la capacité d'héberger des programmes qui sont exécutés sur des machines clientes. Ces programmes peuvent prendre de nombreuses formes, notamment des scripts Web, des exécutables, des modules de plug-in et des macros dans des documents. WebDAV ne modifie aucune des préoccupations de sécurité autour de ces programmes, mais WebDAV est souvent utilisé dans des contextes où un large éventail d'utilisateurs peut publier des documents sur un serveur. Le serveur peut ne pas avoir une relation de confiance étroite avec l'auteur qui publie le document. Les serveurs qui permettent aux clients de publier du contenu arbitraire peuvent utilement mettre en œuvre des précautions pour vérifier que le contenu publié sur le serveur n'est pas nuisible aux autres clients. Les serveurs pourraient le faire par des techniques telles que la restriction des types de contenu autorisés à être publiés et l'exécution de logiciels de détection de virus et de logiciels malveillants sur le contenu publié. Les serveurs peuvent également atténuer le risque en ayant des restrictions d'accès appropriées et une authentification des utilisateurs autorisés à publier du contenu sur le serveur.

21. IANA Considerations (Considérations IANA)​

21.1. New URI Schemes (Nouveaux schémas URI)​

Cette spécification définit deux schémas URI:

  1. le schéma "opaquelocktoken" défini dans l'Annexe C, et

  2. le schéma URI "DAV", qui était historiquement utilisé dans [RFC2518] pour désambiguïser les noms de propriétés WebDAV et les noms d'éléments XML et qui continue à être utilisé à cette fin dans cette spécification et dans d'autres extensions de WebDAV. La création d'identifiants dans l'espace de noms "DAV:" est contrôlée par l'IETF.

Notez que la définition de nouveaux schémas URI pour les espaces de noms XML est maintenant découragée. "DAV:" a été défini avant l'émergence des meilleures pratiques standard.

21.2. XML Namespaces (Espaces de noms XML)​

Les espaces de noms XML désambiguïsent les noms de propriétés WebDAV et les éléments XML. Tout utilisateur ou application WebDAV peut définir un nouvel espace de noms afin de créer des propriétés personnalisées ou d'étendre la syntaxe XML de WebDAV. L'IANA n'a pas besoin de gérer de tels espaces de noms, noms de propriétés ou noms d'éléments.

21.3. Message Header Fields (Champs d'en-tête de message)​

Les champs d'en-tête de message ci-dessous doivent être ajoutés au registre permanent (voir [RFC3864]).

21.3.1. DAV​

Header field name (Nom du champ d'en-tête): DAV

Applicable protocol (Protocole applicable): http

Status (Statut): standard

Author/Change controller (Auteur/Contrôleur de changement): IETF

Specification document (Document de spécification): this specification (Section 10.1)

21.3.2. Depth​

Header field name (Nom du champ d'en-tête): Depth

Applicable protocol (Protocole applicable): http

Status (Statut): standard

Author/Change controller (Auteur/Contrôleur de changement): IETF

Specification document (Document de spécification): this specification (Section 10.2)

21.3.3. Destination​

Header field name (Nom du champ d'en-tête): Destination

Applicable protocol (Protocole applicable): http

Status (Statut): standard

Author/Change controller (Auteur/Contrôleur de changement): IETF

Specification document (Document de spécification): this specification (Section 10.3)

21.3.4. If​

Header field name (Nom du champ d'en-tête): If

Applicable protocol (Protocole applicable): http

Status (Statut): standard

Author/Change controller (Auteur/Contrôleur de changement): IETF

Specification document (Document de spécification): this specification (Section 10.4)

21.3.5. Lock-Token​

Header field name (Nom du champ d'en-tête): Lock-Token

Applicable protocol (Protocole applicable): http

Status (Statut): standard

Author/Change controller (Auteur/Contrôleur de changement): IETF

Specification document (Document de spécification): this specification (Section 10.5)

21.3.6. Overwrite​

Header field name (Nom du champ d'en-tête): Overwrite

Applicable protocol (Protocole applicable): http

Status (Statut): standard

Author/Change controller (Auteur/Contrôleur de changement): IETF

Specification document (Document de spécification): this specification (Section 10.6)

21.3.7. Timeout​

Header field name (Nom du champ d'en-tête): Timeout

Applicable protocol (Protocole applicable): http

Status (Statut): standard

Author/Change controller (Auteur/Contrôleur de changement): IETF

Specification document (Document de spécification): this specification (Section 10.7)

21.4. HTTP Status Codes (Codes d'état HTTP)​

Cette spécification définit les codes d'état HTTP

  • 207 Multi-Status (Section 11.1)
  • 422 Unprocessable Entity (Section 11.2),
  • 423 Locked (Section 11.3),
  • 424 Failed Dependency (Section 11.4) et
  • 507 Insufficient Storage (Section 11.5),

à mettre à jour dans le registre à http://www.iana.org/assignments/http-status-codes.

Note: le code d'état HTTP 102 (Processing) a été supprimé dans cette spécification; son enregistrement IANA doit continuer à référencer RFC 2518.

22. Acknowledgements (Remerciements)​

Une spécification telle que celle-ci prospère grâce à un examen critique approfondi et dépérit en raison d'une négligence apathique. Les auteurs reconnaissent avec gratitude les contributions des personnes suivantes, dont les idées ont été si précieuses à chaque étape de notre travail.

Contributeurs à RFC 2518​

Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse et Lauren Wood.

Deux personnes de cette liste méritent une mention spéciale. Les contributions de Larry Masinter ont été inestimables; il a à la fois aidé à la formation du groupe de travail et a patiemment encadré les auteurs tout au long du processus. De tant de façons, il a établi des normes élevées que nous avons peiné à atteindre. Les contributions de Judith Slein ont également été inestimables; en clarifiant les exigences et en examinant patiemment version après version, elle a à la fois amélioré cette spécification et élargi nos esprits sur la gestion des documents.

Nous aimerions également remercier John Turner pour avoir développé la DTD XML.

Les auteurs de RFC 2518 étaient Yaron Goland, Jim Whitehead, A. Faizi, Steve Carter et D. Jensen. Bien que leurs noms aient dû être supprimés en raison des restrictions de comptage d'auteurs de l'IETF, ils peuvent s'attribuer le mérite de la majorité de la conception de WebDAV.

Remerciements supplémentaires pour cette spécification​

Les contributeurs importants de texte pour cette spécification sont listés comme contributeurs dans la section ci-dessous. Nous devons également reconnaître avec gratitude Geoff Clemm, Joel Soderberg et Dan Brotsky pour avoir élaboré un texte spécifique sur la liste ou lors de réunions. Joe Hildebrand et Cullen Jennings ont aidé à résoudre de nombreux problèmes. Barry Lind a décrit une considération de sécurité supplémentaire et Cullen Jennings a fourni le texte pour cette considération. Jason Crawford a suivi l'état des problèmes pour ce document pendant une période de plusieurs années, suivi par Elias Sinderson.

Annexe A. Notes on Processing XML Elements (Notes sur le traitement des éléments XML)​

A.1. Notes on Empty XML Elements (Notes sur les éléments XML vides)​

XML prend en charge deux mécanismes pour indiquer qu'un élément XML n'a aucun contenu. Le premier consiste à déclarer un élément XML de la forme &lt;A>&lt;/A>. Le second consiste à déclarer un élément XML de la forme &lt;A/>. Les deux éléments XML sont sémantiquement identiques.

A.2. Notes on Illegal XML Processing (Notes sur le traitement XML illégal)​

XML est un format de données flexible qui permet de soumettre facilement des données qui semblent légales mais ne le sont pas en réalité. La philosophie "Soyez flexible dans ce que vous acceptez et strict dans ce que vous envoyez" s'applique toujours, mais elle ne doit pas être appliquée de manière inappropriée. XML est extrêmement flexible dans le traitement des questions d'espaces blancs, d'ordre des éléments, d'insertion de nouveaux éléments, etc. Cette flexibilité ne nécessite pas d'extension, en particulier dans le domaine de la signification des éléments.

Il n'y a aucune gentillesse à accepter des combinaisons illégales d'éléments XML. Au mieux, cela provoquera un résultat indésirable et au pire, cela peut causer des dommages réels.

A.3. Example - XML Syntax Error (Exemple - Erreur de syntaxe XML)​

Le corps de requête suivant pour une méthode PROPFIND est illégal.

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:">
 &lt;D:allprop/>
 &lt;D:propname/>
&lt;D:propfind>

La définition de l'élément propfind ne permet que l'élément allprop ou l'élément propname, pas les deux. Ainsi, ce qui précède est une erreur et doit recevoir une réponse 400 (Bad Request).

Imaginez cependant qu'un serveur veuille être "gentil" et décide de choisir l'élément allprop comme véritable élément et d'y répondre. Un client fonctionnant sur une ligne à bande passante limitée qui avait l'intention d'exécuter un propname serait très surpris si le serveur traitait la commande comme un allprop.

De plus, si un serveur était indulgent et décidait de répondre à cette demande, les résultats varieraient de manière aléatoire d'un serveur à l'autre, certains serveurs exécutant la directive allprop et d'autres exécutant la directive propname. Cela réduit l'interopérabilité au lieu de l'augmenter.

A.4. Example - Unexpected XML Element (Exemple - Élément XML inattendu)​

L'exemple précédent était illégal car il contenait deux éléments explicitement interdits d'apparaître ensemble dans l'élément propfind. Cependant, XML est un langage extensible, on peut donc imaginer de nouveaux éléments définis pour être utilisés avec propfind. Voici le corps de requête d'un PROPFIND et, comme l'exemple précédent, doit être rejeté avec un 400 (Bad Request) par un serveur qui ne comprend pas l'élément expired-props.

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
 &lt;E:expired-props/>
&lt;D:propfind>

Pour comprendre pourquoi un 400 (Bad Request) est renvoyé, examinons le corps de requête tel que le serveur non familier avec expired-props le voit.

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:"
            xmlns:E="http://www.example.com/standards/props/">
&lt;D:propfind>

Comme le serveur ne comprend pas l'élément 'expired-props', selon les règles de traitement XML spécifiques à WebDAV spécifiées dans la section 17, il doit traiter la demande comme si l'élément n'était pas là. Ainsi, le serveur voit un propfind vide, qui selon la définition de l'élément propfind est illégal.

Veuillez noter que si l'extension avait été additive, cela n'aurait pas nécessairement entraîné un 400 (Bad Request). Par exemple, imaginez le corps de requête suivant pour un PROPFIND:

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:"
            xmlns:E="http://www.example.com/standards/props/">
 &lt;D:propname/>
 &lt;E:leave-out>*boss*&lt;E:leave-out>
&lt;D:propfind>

L'exemple précédent contient l'élément fictif leave-out. Son but est d'empêcher le retour de toute propriété dont le nom correspond au modèle soumis. Si l'exemple précédent était soumis à un serveur non familier avec 'leave-out', le seul résultat serait que l'élément 'leave-out' serait ignoré et un propname serait exécuté.

Annexe B. Notes on HTTP Client Compatibility (Notes sur la compatibilité des clients HTTP)​

WebDAV a été conçu pour être, et s'est avéré être, rétrocompatible avec HTTP 1.1. Les méthodes PUT et DELETE sont définies dans HTTP et peuvent donc être utilisées par des clients HTTP ainsi que par des clients conscients de WebDAV, mais les réponses à PUT et DELETE ont été étendues dans cette spécification de manière à ce que seul un client WebDAV soit entièrement préparé. Certaines préoccupations théoriques ont été soulevées quant à savoir si ces réponses causeraient des problèmes d'interopérabilité avec les clients HTTP uniquement, et cette section aborde ces préoccupations.

Étant donné que tout client HTTP devrait gérer les codes d'état de niveau 400 et 500 non reconnus comme des erreurs, les nouveaux codes d'état suivants ne devraient présenter aucun problème: 422, 423 et 507 (424 est également un nouveau code d'état mais il n'apparaît que dans le corps d'une réponse Multistatus.) Ainsi, par exemple, si un client HTTP tentait de faire un PUT ou DELETE sur une ressource verrouillée, la réponse 423 Locked devrait entraîner une erreur générique présentée à l'utilisateur.

La réponse 207 Multistatus est intéressante car un client HTTP émettant une requête DELETE vers une collection pourrait interpréter une réponse 207 comme un succès, même s'il ne réalise pas que la ressource est une collection et ne peut pas comprendre que l'opération DELETE pourrait avoir été un échec complet ou partiel. Cette interprétation n'est pas entièrement justifiée, car une réponse de niveau 200 indique que le serveur "a reçu, compris et accepté" la demande, et non que la demande a abouti à un succès complet.

Une option est qu'un serveur pourrait traiter un DELETE d'une collection comme une opération atomique, et utiliser soit 204 No Content en cas de succès, soit une réponse d'erreur appropriée (niveau 400 ou 500) pour une erreur. Cette approche maximiserait en effet la rétrocompatibilité. Cependant, étant donné que les tests d'interopérabilité et les discussions du groupe de travail n'ont révélé aucune instance de clients HTTP émettant une requête DELETE contre une collection WebDAV, cette préoccupation est plus théorique que pratique. Ainsi, les serveurs sont susceptibles de réussir complètement à interagir avec les clients HTTP même s'ils traitent toute requête DELETE de collection comme une requête WebDAV et envoient une réponse 207 Multi-Status.

En général, les implémentations de serveur sont encouragées à utiliser les réponses détaillées et autres mécanismes définis dans ce document plutôt que d'apporter des modifications pour des préoccupations d'interopérabilité théoriques.

Annexe C. The 'opaquelocktoken' Scheme and URIs (Le schéma 'opaquelocktoken' et les URI)​

Le schéma URI 'opaquelocktoken' a été défini dans [RFC2518] (et enregistré par l'IANA) afin de créer des URI syntaxiquement corrects et faciles à générer à partir d'UUID, destinés à être utilisés comme jetons de verrouillage et à être uniques pour toutes les ressources pour tous les temps.

Un URI opaquelocktoken est construit en concaténant le schéma 'opaquelocktoken' avec un UUID, ainsi qu'une extension optionnelle. Les serveurs peuvent créer de nouveaux UUID pour chaque nouveau jeton de verrouillage. Si un serveur souhaite réutiliser des UUID, le serveur DOIT ajouter une extension, et l'algorithme générant l'extension DOIT garantir que la même extension ne sera jamais utilisée deux fois avec l'UUID associé.

OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
  ; UUID est défini dans la section 3 de [RFC4122]. Notez que LWS
  ; n'est pas autorisé entre les éléments de
  ; cette production.

Extension = path
  ; path est défini dans la section 3.3 de [RFC3986]

Annexe D. Lock-null Resources (Ressources lock-null)​

Le modèle WebDAV original pour le verrouillage d'URL non mappées créait des "ressources lock-null". Ce modèle était trop compliqué et certains problèmes d'interopérabilité et d'implémentation ont été découverts. Le nouveau modèle WebDAV pour le verrouillage d'URL non mappées (voir Section 7.3) crée des "ressources vides verrouillées". Les ressources lock-null sont obsolètes. Cette section discute brièvement du modèle original car les clients DOIVENT être capables de gérer l'un ou l'autre modèle.

Dans le modèle original "ressource lock-null", qui n'est plus recommandé pour l'implémentation:

  • Une ressource lock-null apparaissait parfois comme "Not Found". Le serveur répond avec un 404 ou 405 à toute méthode sauf PUT, MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.

  • Une ressource lock-null apparaît cependant comme un membre de sa collection parente.

  • Le serveur supprime entièrement la ressource lock-null (son URI devient non mappée) si son verrou disparaît avant qu'elle ne soit convertie en ressource régulière. Rappelez-vous que les verrous disparaissent non seulement lorsqu'ils expirent ou sont déverrouillés, mais sont également supprimés si une ressource est renommée ou déplacée, ou si une collection parente est renommée ou déplacée.

  • Le serveur convertit la ressource lock-null en ressource régulière si une requête PUT vers l'URL réussit.

  • Le serveur convertit la ressource lock-null en collection si une requête MKCOL vers l'URL réussit (bien que l'expérience d'interopérabilité ait montré que tous les serveurs ne suivaient pas cette exigence).

  • Les valeurs de propriété étaient définies pour les propriétés DAV:lockdiscovery et DAV:supportedlock mais pas nécessairement pour d'autres propriétés comme DAV:getcontenttype.

Les clients peuvent facilement interagir à la fois avec les serveurs qui prennent en charge l'ancien modèle "ressources lock-null" et le modèle recommandé de "ressources vides verrouillées" en n'essayant que PUT après un LOCK vers une URL non mappée, pas MKCOL ou GET.

D.1. Guidance for Clients Using LOCK to Create Resources (Conseils pour les clients utilisant LOCK pour créer des ressources)​

Un client WebDAV implémenté selon cette spécification peut trouver des serveurs qui créent des ressources lock-null (implémentées avant cette spécification en utilisant [RFC2518]) ainsi que des serveurs qui créent des ressources vides verrouillées. La réponse à la requête LOCK n'indiquera pas quel type de ressource a été créé. Il existe quelques techniques qui aident le client à gérer l'un ou l'autre type.

  • Si le client souhaite éviter de créer accidentellement des ressources lock-null ou vides verrouillées, un en-tête "If-Match: *" peut être inclus avec les requêtes LOCK pour empêcher le serveur de créer une nouvelle ressource.

  • Si une requête LOCK crée une ressource et que le client souhaite ensuite écraser cette ressource en utilisant une requête COPY ou MOVE, le client doit inclure un en-tête "Overwrite: T".

  • Si une requête LOCK crée une ressource et que le client décide ensuite de se débarrasser de cette ressource, une requête DELETE est censée échouer sur une ressource lock-null et UNLOCK devrait être utilisé à la place. Mais avec une ressource vide verrouillée, UNLOCK ne fait pas disparaître la ressource. Par conséquent, le client pourrait devoir essayer les deux requêtes et ignorer une erreur dans l'une des deux requêtes.

Annexe F. Summary of Changes from RFC 2518 (Résumé des modifications par rapport à RFC 2518)​

Cette annexe fournit un résumé des modifications par rapport à RFC 2518.

F.1. Changes for Both Client and Server Implementations (Modifications pour les implémentations client et serveur)​

Clarifications:

  • Ajout d'une clarification sur les fonctionnalités HTTP qui doivent être prises en charge.
  • Ajout d'une clarification sur le moment où les ETag doivent être renvoyés.
  • Clarification que la collection racine ne peut jamais être supprimée.
  • Clarification que les clients doivent être capables de gérer la réponse PROPFIND contenant des propriétés dans n'importe quel ordre.
  • Clarification des exigences pour les requêtes PROPFIND Depth infinity.
  • Ajout d'une clarification sur l'utilisation de l'en-tête de requête Timeout.
  • Ajout d'une clarification sur la gestion des valeurs de temps.

Clarifications de traitement:

  • Clarification du moment où les en-têtes If de HTTP peuvent être utilisés à la place de l'en-tête If de WebDAV.
  • Clarification que les clients WebDAV doivent être capables de gérer les réponses 401 lors de l'interaction avec un serveur WebDAV.

Conseils améliorés:

  • Ajout de conseils sur l'utilisation de l'en-tête DAV.
  • Ajout de conseils pour la gestion des en-têtes conditionnels HTTP.
  • Ajout de conseils pour la gestion de la requête PROPFIND sur les collections avec un nombre excessif de ressources.
  • Ajout d'un exemple de réponse PROPFIND et clarification des exigences de format.
  • Ajout d'un exemple de requête COPY et clarification de la gestion de l'en-tête Overwrite.

Nouvelle fonctionnalité:

  • Le code d'état 102 (Processing) a été supprimé de cette spécification. Il n'a pas été largement implémenté et a été déplacé vers RFC 2518.

F.2. Changes for Client Implementations (Modifications pour les implémentations client)​

Nouveaux conseils:

  • Ajout d'une annexe sur l'extensibilité XML.
  • Ajout d'une annexe sur l'authentification des clients.
  • Ajout de considérations de sécurité sur les implications des entités XML.

Modifications de traitement:

  • Les clients n'ont plus à échouer lorsqu'ils reçoivent un ordre invalide d'éléments dans une réponse.

F.3. Changes for Server Implementations (Modifications pour les implémentations serveur)​

Ressources lock-null:

  • Les ressources lock-null prises en charge par le serveur ont été dépréciées en faveur des ressources vides verrouillées.
  • Les serveurs peuvent toujours prendre en charge les ressources lock-null pour la compatibilité descendante.

Modifications de propriété:

  • Modification d'un certain nombre de définitions de propriétés pour les rendre plus cohérentes et claires.
  • Propriété DAV:getetag rendue obligatoire où DAV:getlastmodified est requis.
  • Suppression de l'exigence DAV:getcontenttype sur les collections.

Rapport d'erreur:

  • Ajout d'éléments XML de précondition/postcondition pour une meilleure notification d'erreur dans le corps de la réponse.
  • Ajout de conseils sur l'utilisation des préconditions et postconditions.

Comportement COPY/MOVE:

  • Clarification du comportement COPY/MOVE en ce qui concerne les propriétés.
  • Clarification du comportement COPY/MOVE avec les verrous.
  • Clarification du comportement COPY/MOVE en ce qui concerne l'en-tête Depth.

Gestion des verrous:

  • Clarification que le champ propriétaire de verrou dans une requête LOCK n'est pas authentifié.
  • Clarification du moment où les verrous doivent expirer et quand ils peuvent être prolongés.
  • Ajout d'une clarification de l'élément LockInfo.
  • Correction du schéma DAV:supportedlock.

Autres modifications serveur:

  • Clarification du moment où les serveurs doivent utiliser les réponses 404 vs 405.
  • Clarification du comportement DELETE de collection et du rapport d'erreur.
  • Clarification des exigences de transaction PROPPATCH.
  • La méthode OPTIONS doit inclure l'en-tête "DAV" dans les réponses.

F.4. Clarifications to XML Processing (Clarifications sur le traitement XML)​

Validation:

  • Clarification des niveaux d'exigence pour le traitement et la validation XML.
  • Clarification que les règles de traitement XML ne s'appliquent qu'aux éléments définis par WebDAV.
  • Ajout de conseils sur la gestion des éléments XML inconnus.

Gestion des espaces de noms:

  • Clarification de l'utilisation des espaces de noms dans les propriétés et les éléments XML.
  • Clarification que les noms de propriété sont toujours qualifiés.

Modifications DTD:

  • La DTD a été supprimée de la spécification. Elle n'a jamais été normative et était parfois incorrecte ou incomplète.

F.5. Clarifications to Protocol Details (Clarifications sur les détails du protocole)​

Clarifications des codes d'état:

  • Clarification du moment où chaque code d'état WebDAV doit ou devrait être utilisé.
  • Clarification de l'interaction des codes d'état WebDAV avec les codes d'état HTTP.

Clarifications des en-têtes:

  • Clarification de l'utilisation de l'en-tête Depth avec diverses méthodes.
  • Clarification de la syntaxe et du traitement de l'en-tête If.
  • Clarification de l'utilisation de l'en-tête Overwrite.

Format de réponse:

  • Exigences rendues plus claires pour le formatage de la réponse Multi-Status.
  • Gestion href rendue cohérente dans toutes les utilisations.

Gestion des erreurs:

  • Amélioration de la gestion des erreurs tout au long en utilisant des éléments de précondition/postcondition.
  • Ajout de conseils spécifiques pour la gestion des échecs d'autorisation.