Ce document est une traduction de la proposition technique HTTP Extensions for Distributed Authoring -- WEBDAV de The Internet Society, datée de février 1999. Cette version traduite peut contenir des erreurs absentes de l'original, dues à la traduction elle-même. La version originale en anglais, la seule à pouvoir servir de référence, se trouve à l'adresse http://www.webdav.org/specs.
 
Traducteur :
Jean-Jacques Thomasson
Traduction hébergée par XMLfr.
Copyright © 1999 The Internet Society, tous droits réservés.
 
Note de traduction: Le caractère "oe" ligaturé n'étant pas supporté par certains navigateurs, il sera écrit sous la forme de deux caractères non ligaturés : oe.


Extensions de HTTP pour la rédaction distribuée (WEBDAV)

proposition de normalisation
Note d'appel à commentaires numéro 2518 de février 1999

Réalisée par le groupe de travail sur les réseaux de The Internet Society
Cette version a été traduite à partir de la version:
HTTP Extensions for Distributed Authoring -- WEBDAV
Dernière version en langue de référence :
http://www.webdav.org/specs/
Versions précédentes :
Aucune
Auteurs du document original:
Y. Goland, Microsoft Corporation, <yarong@microsoft.com>
E J. Whitehead, Jr., University of California, <ejw@ics.uci.edu>
A Faizi,  Netscape, <asad@netscape.com>
D Jensen, Novell, <dcjensen@novell.com>

Statut de cette note :
Ce document fournit à la communauté Internet une piste vers des protocoles Internet standards, et sert de force de discussion et de propositions pour lui apporter des améliorations. Référez-vous s'il vous plait à l'édition courante de "Internet Official Protocol Standards" (STD 1) pour connaître l'état de standardisation et le statut de ce protocole. La distribution de cette note est libre.
Droits d'auteurs (Copyright) :
Copyright (C) The Internet Society (1999). Tous droits réservés.
Résumé :
Ce document contient les spécifications d'un ensemble de méthodes, entêtes, et de types de contenus auxiliaires à HTTP/1.1 pour la gestion des propriétés des ressources, la création et la gestion de collections de ressources, la manipulation d'espaces de noms, et le verrouillage des ressources (pour éviter les collisions).


Table des matières

Résumé
1 Introduction
2 Conventions d'écriture
3 Terminologie
4 Modèle de données des propriétés des ressources
4.1 Modèle des propriétés de ressource
4.2 Propositions en cours pour les méta-données
4.3 Propriétés et entêtes HTTP
4.4 Valeurs des propriétés
4.5 Noms des propriétés
4.6 Liens indépendants des médias
5 Collections de ressources WEB
5.1 Modèle de l'espace de noms d'URL HTTP
5.2 Collection de ressources
5.3 Création et extraction de collections de ressources
5.4 Ressources source et ressources de sortie
6 Verrouillage
6.1 Verrous exclusifs et partagés
6.2 Support requis
6.3 Marqueurs de verrous
6.4 schéma URI du marqueur de verrou opaquelocktoken
6.4.1 Génération du champ noeud sans passer par une adresse IEEE 802
6.5 Exploration des possibilités de verrouillage
6.6 Exploration des verrous actifs
6.7 Considérations d'utilisation
7 Verrou d'écriture
7.1 Méthodes restreintes par les verrous d'écriture
7.2 Verrous d'écriture et marqueurs de verrous
7.3 Verrous d'écriture et propriété
7.4 Verrous d'écriture sur des ressources nulles
7.5 Verrous d'écriture sur des collections
7.6 Verrous d'écriture et entête de requête If
7.6.1 Exemple - verrou d'écriture
7.7 Verrous d'écriture et méthodes copy/move
7.8 Rafraîchissement des verrous d'écriture
8 Méthodes HTTP pour la rédaction distribuée
8.1 Méthode PROPFIND
8.1.1 Exemple - obtenir des propriétés nommées
8.1.2 Exemple - utilisation de allprop pour obtenir toutes les propriétés
8.1.3 Exemple - utilisation de propname pour obtenir les noms de toutes les propriétés
8.2 Méthode PROPPATCH
8.2.1 Codes d'états à utiliser avec des méthodes multi-états 207
8.2.2 Exemple - méthode PROPPATCH
8.3 Méthode MKCOL
8.3.1 Requête
8.3.2 Codes d'états
8.3.3 Exemple - méthde MKCOL
8.4 Méthodes GET et HEAD appliquées à des collections
8.5 Méthode POST appliquée à des collections
8.6 Méthode DELETE
8.6.1 Méthode DELETE appliquée à des ressources autres que des collections
8.6.2 Méthode DELETE appliquée à des collections
8.7 Méthode PUT
8.7.1 Méthode PUT pour des ressources autres que des collections
8.7.2 Méthode PUT pour des collections
8.8 Méthode COPY
8.8.1 Méthode COPY pour des ressources HTTP/1.1
8.8.2 Méthode COPY appliquée à des propriétés
8.8.3 Méthode COPY appliquée à des collections
8.8.4 Méthode COPY et entête Overwrite
8.8.5 Codes d'états
8.8.6 Exemple - COPY avec overwrite
8.8.7 Exemple - COPY sans overwrite
8.8.8 Exemple - COPY sur une collection
8.9 Méthode MOVE
8.9.1 Méthode MOVE appliquée aux propriétés
8.9.2 Méthode MOVE appliquée à des collections
8.9.3 Méthode MOVE et l'entête overwrite
8.9.4 Codes d'état
8.9.5 Exemple - MOVE d'une ressource autre qu'une collection
8.9.6 Exemple - MOVE d'une collection
8.10 Méthode LOCK
8.10.1 Fonctionnement
8.10.2 L'effet des verrous sur les propriétés et les collections
8.10.3 Verrouillage des ressources dupliquées
8.10.4 Valeur de Depth et verrouillage
8.10.5 Interaction avec d'autres méthodes
8.10.6 Tableau de compatibilité des verrous
8.10.7 Codes d'état
8.10.8 Exemple - une demande de verrouillage simple
8.10.9 Exemple - rafraîchissement d'un verrou d'écriture
8.10.10 exemple - requête de verrou sur plusieurs ressources
8.11 Méthode UNLOCK
8.11.1 Exemple - UNLOCK
9 Les entêtes HTTP pour la rédaction distribuée
9.1 Entête DAV
9.2 Entête Depth
9.3 Entête Destination
9.4 Entête If
9.4.1 Règle de production de No-tag-list
9.4.2 Règle de production de Tagged-list
9.4.3 Règle de production inverse (not )
9.4.4 Fonction matching
9.4.5 Entêtes If et les proxies non conformes DAV
9.5 Entête de marqueur de verrou (Lock-Token)
9.6 Entête Overwrite
9.7 entête de réponse Status-URI
9.8 Entête de requête Timeout
10 Extensions des codes d'état de HTTP/1.1
10.1 Code d'état 102 : Traitements
10.2 Code d'état 207 : Etats multiples
10.3 Code d'état 422 : Entité impossible à traiter
10.4 Code d'état 423 : verrouillé
10.5 Code d'état 424 : Dépendance échue
10.6 Code d'état 507 : Mémoire insuffisante
11 Réponse d'états multiples
12 Définitions des éléments XML
12.1 Elément XML activelock
12.1.1 Elément XML depth
12.1.2 Elément XML locktoken
12.1.3 Elément XML timeout
12.2 Elément XML collection
12.3 Elément XML href
12.4 Elément XML link
12.4.1 Elément XML dst
12.4.2 Elément XML src
12.5 Elément XML lockentry
12.6 Elément XML lockinfo
12.7 Elément XML lockscope
12.7.1 Elément XML exclusive
12.7.2 Elément XML shared
12.8 Elément XML locktype
12.8.1 Elément XML write
12.9 Elément XML multistatus
12.9.1 Elément XML response
12.9.2 Elément XML responsedescription
12.10 Elément XML owner
12.11 Elément XML prop
12.12 Elément XML propertybehavior
12.12.1 Elément XML keepalive
12.12.2 Elément XML omit
12.13 Elément XML propertyupdate
12.13.1 Elément XML remove
12.13.2 Elément XML set
12.14 Elément XML propfind
12.14.1 Elément XML allprop
12.14.2 Elément XML propname
13 Propriétés DAV
13.1 Propriété creationdate
13.2 Propriété displayname
13.3 Propriété getcontentlanguage
13.4 Propriété getcontentlength
13.5 Propriété getcontenttype
13.6 Propriété getetag
13.7 Propriété getlastmodified
13.8 Propriété lockdiscovery
13.8.1 Exemple - obtenir la propriété lockdiscovery
13.9 Propriété resourcetype
13.10 Propriété source
13.10.1 Exemple - une propriété source
13.11 Propriété supportedlock
13.11.1 Exemple - extraire la propriété supportedlock
14 Règles pour la prise en compte de XML dans DAV
15 Classes conformes DAV
15.1 Classe 1
15.2 Classe 2
16 Considérations sur l'internationalisation
17 Considérations sur la sécurité
17.1 Authentification des clients
17.2 Blocage du service
17.3 La sécurité par l'obscurité
17.4 Considérations sur la confidentialité par rapport aux verrous
17.5 Considérations sur la confidentialité par rapport aux propriétés
17.6 Réduction de la sécurité à cause des liens de type source
17.7 Conséquences de l'usage d'entités externes XML
17.8 Risques en relation avec les marqueurs de verrous
18 Considérations relatives à l'IANA
19 Propriété intellectuelle
20 Avertissements
21 Références
21.1 Références normatives
21.2 Références informatives
22 Adresses des auteurs
23 Annexes
23.1 Annexe 1 - Définition de Type de Document (DTD) de WEBDAV
23.2 Annexe 2 - Profil ISO 8601 pour les indications de date et de temps
23.3 Annexe 3 - Notes sur le traitement des éléments XML
23.3.1 Notes sur les éléments vides XML
23.3.2 Notes sur les traitements XML interdits
23.4 Annexe 4 -- Les espaces de noms XML pour WebDAV
23.4.1 Introduction
23.4.2 Signification des noms qualifiés
24 COPYRIGHT complet

1 Introduction

Ce document décrit une extension du protocole HTTP/1.1 qui permet aux clients WEB de participer à des processus éditoriaux à distance. Cette extension fournit un ensemble cohérent de méthodes, entêtes, formats de corps de requêtes et de réponses qui permettent de faire les opérations suivantes :

Le raisonnement et les conditions requises pour ces opérations sont décrits dans un document annexe intitulé "Conditions nécessaires au protocole d'écriture et de versionnement distribués pour le World Wide Web" [RFC2291].

Les sections ci-dessous forment une introduction détaillée aux propriétés des ressources (section 4), les collections de ressources (section 5), les opérations de verrouillage (section 6). Ces sections introduisent les abstractions manipulées par les méthodes HTTP spécifiques à WebDav décrites à la section section 8, "méthodes HTTP pour l'écriture distribuée".

Dans HTTP/1.1, les paramètres passés aux méthodes étaient exclusivement codés dans les entêtes HTTP. WebDav, au contraire, code ces informations soit dans le corps d'une entité requête en utilisant le format XML (eXtensible Markup Language) [REC-XML], soit dans une entête HTTP. Le choix de l'utilisation de XML pour coder les paramètres d'une méthode a été motivé par la possibilité qu'offre ce langage de pouvoir rajouter des éléments à des structures existantes, apportant ainsi l'extensibilité attendue et par la possibilité qu'offre XML de pouvoir coder l'information en utilisant les jeux de caractères ISO 10646, afin de garantir un support international. Comme règle générique, on retiendra que les paramètres sont codés dans le corps XML des requêtes quand leur longueur est quelconque, ou qu'ils peuvent être vus par un regard humain, ce qui nécessite un codage des caractères en ISO 10646 et qu'ils sont codés à l'intérieur des entêtes HTTP dans les autres cas. La section 9 décrit les nouvelles entêtes HTTP utilisées avec les méthodes WebDAV.

Au delà de son utilisation pour le codage des paramètres des méthodes, XML est utilisé dans WebDav pour coder les réponses aux méthodes, apportant ainsi les avantages de l'extensibilité et de l'internationalisation de XML dans les deux cas de figure.

Les éléments XML utilisés dans cette spécification sont définis dans la section 12.

L'extension de l'espaces de noms XML (Annexe 4) est aussi utilisée dans cette spécification afin d'autoriser l'usage de nouveaux éléments XML sans que ceux-là rentrent en collision avec d'autres.

Bien que les codes d'états fournis par HTTP/1.1 soient suffisants pour prendre en charge la plupart des cas d'erreur des méthodes WebDAV, il existe quelques cas d'erreurs qui ne tombent pas nettement dans les catégories existantes. Les nouveaux codes d'états développés pour les méthodes WebDav sont définis dans la section 10. Comme il existe quelques méthodes WebDav qui peuvent agir sur plusieurs ressources, les réponses de type états multiples ont été introduites pour retourner des informations d'états concernant plusieurs ressources. La réponse d'états multiples est décrite dans la section 11.

WebDAV utilise le mécanisme des propriétés pour renregistrer l'état courant d'une ressource. Par exemple, qaund un verrou est posé sur une ressource, une propriété d'information de verrou permet de connaître l'état courant du verrou. La section 13 définit les propriétés utilisées avec les spécifications WebDAV.

La fin de la spécification contient des sections portant sur la compatibilité (section 15), sur le support de l'internationalisation (section 16), et la sécurité(section 17).

2 Conventions d'écriture

Ce document décrivant un ensemble d'extensions au protocole HTTP/1.1, l'extension de la BNF utilisée ici pour spécifier les éléments du protocole est exactement la même que celle décrite à la section 2.1 de [RFC2068] et s'appuie également sur les règles de production de base fournies à la section 2.2 de [RFC2068].

Les mots clés "DOIT", "NE DOIT PAS", "REQUIS", "DEVRA", "NE DEVRA PAS", "DEVRAIT", NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT" et "OPTIONNEL" utilisés dans ce document doivent être interprétés tel que décrit dans le document RFC 2119 [RFC2119].

3 Terminologie

URI/URL : respectivement "Identifiant Uniforme de Ressource" (Uniform Resource Identifier) et "Adresse Uniforme de Ressource" (Uniform Resource Locator). Ces termes (et la distinction entre les deux) sont définis dans le document [RFC2396].

Collection : Une collection est une ressource composée d'un ensemble d'URI, celles des membres appelés. Elles identifient les ressources membres et doivent être conformes aux conditions décrites dans la section 5 de cette spécification.

URI membre : Toute URI de l'ensemble d'URI constituant une collection.

URI membre interne : Une URI membre en relation directe avec l'URI de la collection (la définition de ce que signifie "en relation directe" est écrite à la section 5.2).

Propriété : Une paire composée d'un nom et d'une valeur permettant de décrire les caractéristiques de la ressource.

Propriété vivante : Une propriété dont la sémantique et la syntaxe sont imposées par le serveur. Par exemple, la valeur de la propriété vivante "getcontentlength", en l'occurrence la longueur de l'entité retournée par une requête GET, est calculée dynamiquement par le serveur.

Propriété morte : Une propriété dont la sémantique et la syntaxe ne sont pas imposées par le serveur. Le serveur ne fait qu'en enregistrer la valeur et il revient au poste client d'en garantir la cohérence syntaxique et sémantique.

Resource NULL : Une ressource qui retourne une erreur 404 (message "pas trouvée") en réponse à toute méthode HTTP/1.1 ou DAV sauf dans le cas des méthodes PUT, MKCOL, OPTIONS et LOCK. Une ressource NULL NE DOIT PAS apparaître dans la liste des membres de sa collection parent.

4 Modèle de données des propriétés des ressources

4.1 Modèle des propriétés de ressource

Les propriétés sont une partie des données des la ressource dont elle servent à en décrire l'état. En quelque sorte, les propriétés sont des données qui décrivent des données.

Les propriétés sont utilisées dans les environnements de rédaction distribuée afin de fournir des moyens efficaces de recherche et de gestion des ressources. Par exemple, une propriété qui s'appellerait 'subject' peut permettre de faire une indexation des ressources par sujet, et une propriété 'author' offrirait la possibilité de rechercher les documents à partir des noms de leurs auteurs.

Le modèle des propriétés DAV est formé du couple nom/valeur. Le nom d'une propriété permet d'en connaître la syntaxe et la sémantique, et fournit une adresse par laquelle on peut faire référence à cette syntaxe et cette sémantique.

Il y a deux catégories de propriétés : les propriétés "vivantes" et la propriétés "mortes". Une propriété vivante a sa syntaxe et sa sémantique imposées par le serveur. Les propriétés vivantes comprennent les cas où a) la valeur de la propriété est en lecture seule et elle est maintenue par le serveur, et b) la valeur de la propriété est maintenue par le client et le serveur contrôle la syntaxe des valeurs transmises. Toutes les instances d'une propriété vivante DOIVENT être conformes à la définition qui a été associée au nom de cette propriété. Une propriété morte a sa syntaxe et sa sémantique imposées par le client; le serveur ne fait bien souvent qu'en enregistrer la valeur mot à mot.

4.2 Propositions en cours pour les méta-données

Les propriétés ont toujours jouées un rôle très important dans la gestion des grands référentiels de documents, et beaucoup des propositions actuelles intègrent les notions de propriétés, ou sont des discussions relatives au rôle des méta-données sur le Web de manière plus générale. Cela comprend PICS [REC-PICS], PICS-NG, XML, Web Collections, et plusieurs autres propositions concernant la représentation des relations à l'intérieur de HTML. Le travail sur PICS-NG et Web Collections a été poursuivi par le groupe de travail sur RDF (Resource Description Framework) du World Wide Web Consortium. RDF consiste en un modèle de données prévu pour fonctionner en réseau et une représentation XML de ce modèle.

Quelques propositions proviennent des concepts de bibliothèques électroniques. Parmis celles-là se trouve l'ensemble de méta-données Dublin Core [RFC2413] et le Warwick Framework [WF], une structure d'accueil pour différents schémas de méta-données. La littérature contient beaucoup d'exemples de méta-données, par exemple MARC [USMARC], un format de méta-données pour les bibliographies, et le rapport technique sur le format de bibliographie utilisé par le système Dienst [RFC1807]. De plus, les minutes de la première conférence de l'IEEE sur les méta-données fournissent une grande variété d'ensembles de méta-données qui ont été développés pour les besoins spécifiques de communautés particulières.

Les participants à la séance de travail "Metadata II" en 1996 à Warwick, UK [WF], ont pu noter que "de nouveaux ensembles de méta-données se développeront parallèllement à l'évolution de l'infrastructure réseau" et que "différentes communautés proposeront, concevront, et seront responsables de différents types de méta-données". Ces observations peuvent être corrobhorées en notant que plusieurs ensembles de méta-données spécifiques à des communautés particulières existent déjà, et qu'il existe une réelle motivation à développer de nouvelles formes de méta-données au fur et à mesure que le nombre de communautés utilisant des données sous forme numérique augmente, ce qui exige d'avoir un format de méta-données qui permette de les identifier et de les cataloguer.

4.3 Propriétés et entêtes HTTP

Des propriétés exsitent déjà, d'une certaine manière, dans les entêtes des messages HTTP. Toutefois, dans les environnements de rédaction distribuée, un nombre relativement élevé de propriétés est nécessaire pour décrire l'état d'une ressource. Les initialiser et les retourner par les seules entêtes HTTP serait inefficace. Aussi, un mécanisme est nécessaire pour permettre à un "principal" d'identifier l'ensemble des propriétés qui le concerne et qu'il a le droit d'initialiser et de lire.

4.4 Valeurs des propriétés

La valeur d'une propriété exprimée en XML DOIT être bien formée.

XML a été retenu parce que c'est un format de données flexible, se décrivant lui-même, structuré, qui supporte des définitions de schémas puissants, et supporte plusieurs jeux de caractères. La nature "auto-descriptive" de XML permet à n'importe quelle valeur de propriété d'être étendue par l'ajout de nouveaux éléments. Des clients plus anciens supporteront les extensions parce qu'ils sauront toujours traiter les données spécifiées dans leur format original et ignorer les éléments rajoutés qu'ils ne comprennent pas. Le support des multiples jeux de caractères en XML permet à toute propriété lisible par l'oeil humain d'être codée et lue dans un jeu de caractères familier à l'utilisateur. Le support par XML de multiples langages humains, par l'utilisation de l'attribut "xml:lang", permet de gérer les cas où un même jeu de caractères est commun à plusieurs langages humains.

4.5 Noms des propriétés

Un nom de propriété est un identifiant universel unique associé à un schéma qui fournit l'information quant à la syntaxe et la sémantique de la propriété.

Une conséquence de l'aspect universel et unique des noms de propriétés et que les données reçues par les applications clientes peuvent dépendre de la régularité de comportement d'une propriété en particulier utilisée dans différentes ressources, que ce soit sur le même serveur ou sur des serveurs différents, et particulièrement si cette propriété est "vivante", le résultat dépendra directement de la fidélité de son implémentation par rapport à sa définition.

Le mécanisme des espaces de noms de XML, qui repose sur des URI s [RFC2396], est utilisé pour nommer les propriétés parce qu'il permet d'éviter les collisions de noms et fournit plusieurs niveaux de contrôles au niveau de leur gestion.

La propriété namespace est plate; c'est à dire qu'elle n'a pas de structure hiérarchique reconnue. C'est à dire que si deux propriétés qui s'écrivent pour l'une A et pour l'autre A/B existent sur une ressource, cela ne signifie qu'il y a une quelconque relation de hiérarchie entre les deux. Une spécification séparée sera éventuellement réalisée sur la question de la hiérarchisation des propriétés.

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

4.6 Liens indépendants des médias

Bien que les liens entre ressources soient supportés avec HTML, le Web a besoin d'un support plus général des liens entre les différents types de média possible (ces types de média sont connus comme étant des types MIME ou des types de contenus). WebDav fournit de tels liens. Un lien WebDav est définit par un type spécifique de propriété, formellement défini à la section 12.4 (élément XML Link) , qui permet de définir des liens entre des ressources de n'importe quel type de média. La valeur de la propriété est constituée des URI (Uniform Resource Identifiers) des ressources sources et destinations des liens; le nom de la propriété identifie le type de lien.

5 Collections de ressources Web

Cette section contient la description d'un nouveau type de ressource Web, le type collection, et discute de ses interactions avec le modèle de l'espace de nom des URL de HTTP. L'objectif d'une ressource de type collection est de modéliser des objets qui sont des regroupements de ressources (par exemple, les répertoires d'un système de fichiers) dans l'espace de noms d'un serveur.

Toutes les ressources compatibles DAV DOIVENT supporter le modèle de l'espace de noms des URL de HTTP comme cela est spécifié comme ci-après.

5.1 Modèle de l'espace de noms d'URL HTTP

L'espace de noms d'URL HTTP est un modèle hiérarchique de noms dans lequel la hiérarchie est syntaxiquement représentée par le caractère "/".

Un espace de noms d'URL HTTP est réputé être régulier quand il répond à la condition suivante : pour toute URL de la hiérachie HTTP il existe une collection parente contenant cette URL comme membre interne ; seule la racine, ou collection de plus haut niveau de l'espace de noms, est exempté de la règle précédente.

Ni HTTP/1.1 ni WebDav n'imposent que la totalité de l'espace de noms d'URL HTTP soit régulier. Cependant, cette spécification précise que certaines méthodes WebDav ne sont pas autorisées à produire des résultats qui rendrait l'espace de noms irrégulier.

Bien que cela soit implcite dans [RFC2068] et [RFC2396], toute ressource, y compris les ressources de type collection, PEUVENT être identifiées par plus d'une URI. Par exemple, une ressource peut être identifiée pas plusieurs URL HTTP.

5.2 Ressources de type collection

Une collection est une ressource dont l'état est constitué d'au moins une liste d'URI de membres internes et d'un ensemble de propriétés ; une collection peut toutefois avoir des états additionels tel que des corps d'entités retournés suite à l'exécution d'une méthode GET. Une URI de membre interne DOIT être en relation directe avec une URI de base de la collection. Cela étant, l'URI du membre interne d'une collection est égale à l'URI de la collection auquel on rajout un segment additionel pour les ressources qui ne sont pas elle-mêmes des collections , ou d'un segment additionel suivi de "/" pour les ressources internes à la collection qui sont elle-mêmes des collections, où le segment est défini dans la section 3.3 du document [RFC2396].

Toute URI qui est un membre interne donné DOIT appartenir à la collection de manière unique, c'est à dire qu'il est interdit d'avoir plusieurs instances de la même URI dans une collection. Les propriétés définies sur des collections ont exactement les mêmes comportement que celles des ressources qui ne sont pas des collections.

Pour toute resource A et B compatible WebDAV, identifiées par les URI s U et V, où U est immédiatement relative à V, B DOIT être une collection ayant U comme URI de membre interne. Ainsi, si les ressources dont les URL http://foo.com/bar/blah et http://foo.com/bar/ sont conformes à WebDav alors la ressource ayant pour URL http://foo.com/bar/ doit être une collection et doit contenir l'URL http://foo.com/bar/blah comme membre interne.

Dans la hiérarchie des espaces de noms d'URL HTTP, les ressources de type collection PEUVENT contenir comme membres internes les URLs d'enfants non-conformes à WebDav mais cela n'est pas exigé. Par exemple, si la ressource ayant l'URL http://foo.com/bar/blah n'est pas conforme à WebDAV et que l'URL http://foo.com/bar/ est identifiée comme étant une collection alors l'URL http://foo.com/bar/blah peut être ou non un membre interne de la collection http://foo.com/bar/.

Si une ressource conforme à WebDav n'a aucun enfant conforme à WebDav dans l'arborescence de l'espace de noms d'URL HTTP alors WebDav n'exige pas que cette ressource soit une collection.

Il existe une convention établie qui dit que lorsque une collection est référencée par son nom sans le slash de fin, le slash de fin est automatiquement rajouté. A cause de cela, une ressource peut accepter une URI sans "/" de fin pout pointer vers une collection. Dans ce cas, elle DEVRAIENT retourner dans sa réponse une entête content-location pointant vers l'URI se finissant par le "/". Par exemple, si un client invoque une méthode portant sur http://foo.bar/blah (pas de "/" à la fin), La ressource http://foo.bar/blah/ (avec un "/" de fin) peut répondre comme si la requête lui avait été appliquée, et en renvoyant dans ce cas une entête content-location contenant http://foo.bar/blah/. En général, les clients DEVRAIENT utiliser la forme avec le "/" pour les noms de collections.

Une ressource PEUT être une collection mais n'être pas conforme à WEBDAV. Cela étant, la ressource peut être conforme à toutes les règles définies dans cette spécification quant à la manière dont doit se comporter une collection sans pour autant supporter toutes les méthodes qu'une ressource conforme à WebDav se doit de supporter. Dans ce cas de figure, la ressource peut retourner la propriété DAV:resourcetype avec la valeur DAV:collection mais NE DOIT PAS retourner la valeur "1" dans l'entête DAV en réponse à la méthode OPTIONS .

5.3 Création et extraction de ressources collection (relue)

Ce document contient la spécification de la méthode MKCOL qui sert à créer de nouvelles ressources de type collection, cela en remplacement des méthodes PUT ou POST d'HTTP/1.1 pour les raisons suivantes :

Dans HTTP/1.1, la définition de la méthode PUT est l'enregistrement du corps de la requête à l'endroit spécifié par l'URI requête. Alors qu'un format de description de collections pourrait tout à fait être conçu à partir de la méthode PUT, les conséquences de l'envoi d'une telle description au serveur seraient indésirables. Par exemple, si la description d'une collection, dans laquelle il manquerait des ressources pourtant bien présentes sur le serveur, était mise par PUT sur le serveur, cela pourrait être interprété comme une commande de destruction des membres correspondant à l'omission. Cela amènerait la méthode PUT à agir comme la fonction DELETE, ce qui est un effet indésirable puisque cela changerait la sémantique de la méthode PUT et rendrait difficile le contrôle de la fonction DELETE reposant un modèle de gestion des droits d'accès basé sur des méthodes.

Alors que la méthode POST est suffisamment ouverte pour qu'une commande POST de type "crée une collection" pourrait être construite, cela est également indésirable parce qu'il serait alors difficile de faire la différence entre cette utilisaiton de la méthode POST et les autres utilisations de POST.

La définition exacte du comportement que les méthodes GET et PUT doivent avoir quand elles sont appliquées à des collections est définie ultérieurement dans ce document.

5.4 Ressources source et ressources de sortie

Dans de nombreux cas de ressources, l'entité retournée par une méthode GET correspond exactement à l'état persistant de la ressource, c'est le cas, par exemple, d'un fichier GIF stocké sur un disque. Dans ce cas simple, l'URI à laquelle la ressource est accédée est identique à l'URI à laquelle la ressource, dans son état persistent, est stockée. C'est aussi le cas des fichiers HTML sources qui sont transmis tel quel au client par le serveur (dans le cas où il n'y a pas de traitement particulier préalable à l'affichage).

Toutefois, il arrive que le serveur traite les ressources HTML avant leur transmission au client en tant que corps d'entité. Par exemple, une directive de type "server-side-include" (SSI) incluse dans un fichier HTML peut donner l'instruction à un serveur de remplacer la directive elle-même par une valeur calculée telle que la date courante. Dans ce cas, le fichier retourné par la méthode GET (le fichier HTML d'origine avec le résultat du calcul de la date) est différent de l'état persistent de la ressource (le fichier HTML d'origine contenant la directive SSI). Il est important de remarquer que dans ce cas typique, il n'y a actuellement aucun moyen d'accéder la ressource HTML source qui contient la directive avant traitement.

Parfois, l'entité retournée par la méthode GET est le résultat d'un programme d'extraction de données décrites par une ou plusieurs ressources sources (qui peuvent même ne pas avoir d'emplacement à l'intérieur même de l'espace de noms de l'URI). Un seul programme d'extraction de données peut, à lui seul, générer dynamiquement un nombre potentiellement important de ressources de sortie. Un exemple caractéristique peut être celui d'un script CGI qui décrit un programme de type passerelle d'indexation mettant en correspondance une partie de l'espace de nom d'un serveur avec une demande d'indexation, par exemple http://www.foo.bar.org/finger_gateway/user@host.

Dans le cas où les fonctions de rédaction distribuée ne sont pas supportées, il est acceptable de ne pas établir de correspondance entre les ressources sources et l'espace de nom URI. En faite, cette forme de protection par rapport aux accés à des ressources sources a un réel effet bénéfique sur la sécurité. Toutefois, si l'édition à distance de la ressource source est souhaitée, elle doit avoir un emplacement dans l'espace de noms de l'URI. L'emplacement de la source ne doit pas se trouver au même endroit que celui où la ressource calculée est accessible, puisque, en général, les serveurs sont incapable, dans ce cas, de faire la distinction entre les demandes qui s'adressent aux ressources sources et celles qui concernent les ressources de sortie calculées. Il y a souvent une relation de type n-n entre les ressources sources et les ressources de sortie.

Sur les serveurs conformes à WebDav l'URI de la ressource source peut être enrégistrée comme un lien vers la ressource de sortie ayant le type DAV:source (se référer à la section 13.10 pour une description de la propriété link de la source). Conserver les URI des sources sous la forme de liens vers les ressources de sortie revient à faire porter au client la charge de découvrir l'emplacement où se trouve réellement la source sur lequel se fait la rédaction. Remarquez qu'il n'est pas garantie que la valeur du lien source pointe vers la bonne source. Les liens vers les sources peuvent être rompus ou des erreurs peuvent avoir été commises au moment de de leur saisie. Remarquez également que tous les serveurs ne permettront pas aux postes clients de fixer les valeurs des liens vers les sources. Par exemple un serveur qui génèrerait pour ses fichiers CGI des liens calculés à la volée (par programme) vers les sources n'autoriserait probablement pas les clients de le faire à sa place.

6 Verrouillage

La possibilité de verrouiller une ressource est un mécanisme permettant de sérialiser les accès à cette ressource. En utilisant un verrou, un client en rédaction fournit une garantie fiable qu'un autre ne viendra pas modifier une ressource qui serait déjà en cours de modification. En faisant cela, un client est protégé contre le problème de "dernière mise à jour perdue".

Cette spécification permet d'avoir différents types de verrous au moyen de deux paramètres spécifiques aux clients, le nombre de demandeurs impliqués (exclusif vs. partagé) et le type d'accés à leur accorder. Ce document définit le verrouillage pour un seul type d'accès : celui en écriture. Toutefois, la syntaxe est extensible et permet la spécification éventuelle de verrouillage pour d'autres types d'accès.

6.1 Verrous exclusifs et partagés

La forme de verrou la plus élémentaire est le verrou exclusif. Il s'agit d'un verrou par lequel le droit d'accès fourni est accordé à un seul demandeur. La raison de cet arbitrage vient du désir de ne pas avoir à résoudre le problème de la fusion des modifications faites sur les sources.

Toutefois, il y a des cas où le but d'un verrou n'est pas d'en empêcher d'autres d'exercer leur droit d'accès mais plutôt de fournir un mécanisme par lequel les demandeurs peuvent signaler leur intention d'exercer leur droit d'accès. Les verrous partagés ont été défini précisément pour ce cas de figure. Un verrou partagé permet à plusieurs demandeurs de recevoir un verrou. Dès lors, tout demandeur ayant un droit d'accès approprié peut obtenir le verrou.

Avec les verrous partagés, il y a deux ensembles d'autorisations pouvant toucher une ressource. Le premier est celui des droits d'accès. Les demandeurs qui sont autorisés peuvent avoir, par exemple, le droit en écriture dans la ressource. Parmi eux, ceux qui ont obtenu un verrou partagé DOIVENT aussi s'autoriser mutuellement : ils constituent alors un sous-ensemble de l'ensemble des droits d'accès.

En considérant tous les demandeurs possible d'Internet, la grande majorité d'entre eux n'auront, dans la pluplart des cas, aucun droit d'accès à une ressource donnée. Parmi le petit nombre qui aura un droit d'accès en écriture, quelques demandeurs voudront s'assurer que leurs éditions seront dégagées de tout risque d'écrasement de données et utiliseront les verrous d'écriture exclusifs. D'autres pourront décider qu'ils ont confiance que leurs collègues n'écraseront pas leur travail (l'ensemble potentiel des collègues étant l'ensemble des demandeurs qui ont les droits en écriture) et utiliseront un verrou partagé, qui permet d'informer les collègues qu'un demandeur est peut être déjà en train de travailler sur la ressource.

Les extensions WebDav de HTTP n'ont pas besoin de fournir tous les moyens de communication nécessaires aux demandeurs pour coordonner leur activité. Quand on utilise des verrous partagés, les demandeurs ont le droit d'utiliser n'importe quel moyen de communication pour coordoner leurs travaux (par exemple, des notes écrites, des réunions, des post-it collés sur les écrans, des conversations téléphoniques, des courriels, etc.). Le but d'un verrou partagé est d'offrir aux collaborateurs la possibilité de connaître l'identité de celui qui travaille déjà sur la ressource.

Les verrous partagés font partie de cette spécification parce que les expériences passées sur les environnements de rédaction collaborative sur le WEB ont montré que les verrous exclusifs sont trop souvent rigides. Un verrou exclusif est utilisé pour imposer un processus rédactionnel particulier : pose d'un verrou exclusif, lecture de la ressource, modification du contenu, écriture de la ressource, libération du verrou. Mais les verrous ne sont pas toujours correctement libérés, par exemple, quand un programme "se plante", ou quand le propriétaire d'un verrou abandonne son travail en cours de route sans déverrouiller la ressource. Alors que l'utilisation de contrôle de temps limite (timeout) et l'intervention humaine d'un administrateur sont les moyens pour supprimer le verrou indésirable, il peut se trouver qu'aucun de ces deux mécanismes ne soit disponible au moment où on en a justement besoin; le contrôle de dépassement de temps peut être long et l'administrateur indisponible.

6.2 Support requis

Il n'est pas exigé que le serveur soit conforme à WebDav pour qu'il sache supporter le verrouillage, quelque en soit la forme. Si le serveur supporte les mécanismes de verrouillage, il peut choisir de supporter n'importe quelle combinaison des formes exclusives et partagées des verrous et pour n'importe quel type d'accès.

La raison de cette souplesse est que les politiques de verrouillage sont intégrées au coeur même des systèmes de gestion et de versionnement des ressources utilisés par différents référentiels de stockage. Ces référentiels ont besoin d'avoir le contrôle sur les types de verrous qui seront disponibles. Par exemple, certains référentiels ne supportent que les verrous d'écriture partagés tandis que d'autres ne supportent que les verrous d'écriture exclusifs et d'autres encore n'en utilisent aucun. Comme chacun de ces systèmes est suffisamment différent pour pouvoir se satisfaire de l'absence de certaines fonctions de verrouillage, cette spécification laisse la question du verrouillage comme étant la seule négotiation possible à l'intérieur de WebDAV.

6.3 Marqueurs de verrous

Un marqueur de verrou est un type de marqueur d'état, représenté comme une URI, qui identifie un verrou particulier. Un marqueur de verrou est retourné, après toute opération de verrouillage réussie, dans la propriété lockdiscovery du corps de la réponse. Il peut également être retrouvée en lançant une recherche de verrou sur la ressource.

Les URI s de marqueurs de verrous DOIVENT être uniques à jamais pour toutes les resources. Cette contrainte d'unicité permet aux marqueurs de verrous d'être utilisés pour toutes les ressources et les serveurs sans crainte de confusion.

Cette spécification fournit un modèle d'URI de marqueur de verrou appelé opaquelocktoken conforme à la contrainte d'unicité. Toutefois, les ressources restent libres de retourner n'importe quel modèle d'URI tant que cellle-là reste conforme à la contrainte d'unicité.

Le fait de pouvoir acccéder aux marqueurs de verrous ne signifie pas pour autant que le demandeur dispose de droits d'accès privilégiés. Tout le monde peut trouver le marqueur de verrou de n'importe quelle autre personne en exécutant simplement une recherche de marqueur. Les verrous DOIVENT être appliqués en fonction des mécanismes d'authentification disponibles sur le serveur, mais qui ne doit pas reposer sur une politique de secret des valeurs des marqueurs.

6.4 Modèle d'URI de marqueur de verrou opaquelocktoken

Le modèle d'URI opaquelocktoken est conçu pour être unique, dans le temps, à travers toutes les ressources. Grâce à cette unicité, un client peut soumettre un marqueur de verrou opaque dans une entête If sur une ressource différente de celle qui l'a retourné initialement.

Toutes les ressources DOIVENT reconnaître le modèle opaquelocktoken et, au minimum, reconnaître que le marqueur de verrou ne fait pas référence à un verrou en suspens de la ressource.

Afin de garantir l'unicité temporelle pour toutes les ressources, le verrou opaquelocktoken nécessite l'utilisation d'un mécanisme reposant sur le principe des identifiants universels uniques (Universal Unique Identifier - UUID-), tel qu'il est décrit dans [ISO-11578].

Les générateurs de verrous Opaquelocktoken , toutefois, ont le choix dans la manière dont ils créent les marqueurs. Ils peuvent soit générer un nouvel UUID pour chaque marqueur de verrou qu'ils créent soit créer un seul UUID puis lui ajouter des caractères d'extension. Si la deuxième méthode est choisie alors le programme de génération des extensions DOIT garantir que la même extension ne sera jamais utilisée deux fois sur le même UUID.

La règle de production de l'UUID est la représentation sous forme de chaîne de caractères d'un UUID, tel que défini dans [ISO-11578]. Notez que l'espace blanc (LWS) n'est pas autorisé entre les éléments de cette règle de production.

OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]

Extension = path

"path" est défini dans la section 3.2.1 de RFC 2068 [RFC2068]

6.4.1 Génération du champ noeud sans passer par une adresse IEEE 802

Les UUIDs, tels que défini dans [ISO-11578], contiennent un champ "noeud" qui contient une des adresses IEEE 802 du serveur. Comme il est dit dans la section 17.8, il y a plusieurs risques relatifs à la sécurité inhérents à l'exposition des adresses IEEE 802 des machines. Cette section fournit un mécanisme alternatif qui permet de générer le champ "noeud" d'un UUID sans utiliser l'adresse IEEE 802. Les serveurs WebDav PEUVENT utiliser cet algorithme pour la création du champ noeud au moment de la génération des UUIDs. Le texte de cette section est issu d'un brouillon sur Internet de Paul Leach et Rich Salz, dont les noms sont rappelés ici afin que leurs travaux soient reconnus comme il se doit.

La solution idéale est d'obtenir un nombre aléatoire de 47 bits de qualité cryptographique, et de l'utiliser comme formant les 47 bits basses de l'ID du noeud, avec le bit de poids fort du premier octet de l'ID du noeud égal à 1. Ce bit est celui réservé au typage unicast/multicast, jamais utilisé dans les adresses IEEE 802 pas les cartes réseaux ; par conséquent, il ne pourra jamais y avoir de conflit entre les UUIDs générés par les machines, qu'elles soient équipées ou non d'une carte réseau.

Si un système n'a pas de fonction de base pour générer des nombres alétoire de cryptage, alors il y a, la plupart du temps, un grand nombre de de possibilités pour trouver une séquence aléatoire permettant de générer une valeur. Les types de données sources listées ci-après dépendent bien sûr du système, mais très souvent on trouve :

(Remarquez que c'est précisément le type de ressources aléatoires mentionnées ci-dessus qui sont utilisées pour alimenter les générateurs de nombres alétoires de qualité cryptographique sur des systèmes dont le matériel n'est pas équipé de fonctions spécifiques pour les générer.)

De plus, des données tels que le nom de l'ordinateur et le nom du système d'exploiation, bien que ne pouvant être qualifiées d'alétoire à proprement parler, pourront aider à faire la diffférence avec les nombres aléatoires produits par d'autres systèmes.

L'algorithme exact de génération d'un identifiant de noeud utilisant ces données est spécifique au système, parce que les données disponibles et les fonctions pour les obtenir sont à la fois et souvent très spécifiques au système. Toutefois, en acceptant que l'on pourrait concaténer toutes les valeurs des sources aléatoires dans un buffer, et qu'une fonction de hachage cryptographique telle que MD5 soit disponible, alors tout mot de 6 octets du buffer de hachage de MD5, ayant le bit multicast initialisé (le bit de poids fort du premier octet) pourra être un identifiant de noeud alétoire acceptable.

D'autres fonctions de hachage, telle que par exemple SHA-1, peuvent aussi être utilisées. La seule obligation est que le résultat soit un nombre aléatoire adapté, c'est à dire qu'à un ensemble d'entrées uniformément distribué produise un ensemble de sorties elles-mêmes uniformément distribuées, et que la modification d'un seul bit en entrée provoque le changement de plus de la moitié des bits de sortie.

6.5 Exploration des possibilités de verrouillage

Puisque le support des verrous au niveau du serveur est optionnel, un client essayant de bloquer une ressource sur un serveur peut soit essayer le verrouillage et espérer que cela marche, soit exécuter une sorte d'exploration pour savoir quelles sont les capacités du serveur à supporter le verrouillage. Cela est connu sous le nom d'exploration des possibilités de verrouillage. Cela est différent de la recherche des types de contrôles d'accès supportés puisque il peut y avoir des types de contrôles d'accès sans verrou correspondant. Un client peut déterminer quels sont les types de verrous supportés par le serveur en récupérant cette information par la propriété supportedlock .

Toute ressource conforme à DAV qui supporte la méthode LOCK DOIT supporter la propriété supportedlock .

6.6 Exploration des verrous actifs

Si un demandeur verrouille la ressource qu'un autre demandeur espère accéder, il est pratique pour le deuxième d'être capable de trouver qui est le premier. Pour cela, il existe la propriété lockdiscovery. Elle liste tous les verrous en suspens, décrit leur type, et, quand ils sont disponibles, fourni les marqueur de verrous qui s'y appliquent.

Toute ressource conforme à DAV qui supporte la méthode LOCK DOIT supporter la propriété lockdiscovery .

6.7 Considérations d'utilisation

Bien que les mécanismes de verrouillage spécifiés dans ce document fournissent une certaine garantie contre le problème de la dernière mise à jour perdue pour cause d'écrasement, ils ne peuvent cependant pas garantir à 100% que les mises à jour ne seront jamais perdues. Imaginez le scénario suivant :

Deux clients A et B souhaitent éditer la même ressource "index.html". Le client A utilise le protocole HTTP plutôt que WebDav , et donc, ne sait pas gérer les verrous.
Le client A ne verrouille pas le document, exécute un GET puis commence l'édition.
Le client B fait un LOCK , exécute un GET et commence l'édition.
Le client B termine l'édition, exécute un PUT , puis un UNLOCK . Le client A exécute un PUT , écrase le fichier et fait perdre à B ses mises à jour.

Il y a plusieurs raisons pour lesquelles le protocole WebDav lui-même ne peut pas anticiper cette situation. La première est qu'il ne peut pas obliger tous les clients à utiliser le verrouillage parce qu'il doit rester compatible avec les clients HTTP qui, eux, ne comprennent pas le verrouillage. Deuxièmement, il ne peut pas exiger des serveurs qu'ils supportent le verrouillage à cause de la variété des implémentations des référentiels, les uns s'appuyant plutôt sur des mécanismes de réservation et de fusion que sur des verrous. Finallement, parce que le protocole est de type "sans gestion d'état" (stateless), il ne peut obliger le client à exécuter une séquence d'opération pré-définie telle que LOCK / GET / PUT / UNLOCK .

Les serveurs WebDav qui supportent le verrouillage réduisent le risque d'avoir des clients écrasant mutuellement et par accident leurs modifications respectives en exigeant d'eux qu'ils bloquent les ressources avant de les modifier. De tels serveurs protègeront effectivement les clients HTTP 1.0 et HTTP 1.1 des modifications indésirables des ressources.

Les clients WebDav peuvent être de bons citoyens utilisant la séquence d'opérations lock / retrieve / write /unlock (au moins par défaut) chaque fois qu'ils interagiront avec un serveur WebDav qui supportera le verouillage.

Les clients HTTP 1.1 peuvent être de bons citoyens, c'est à dire en évitant d'écraser les changements faits par d'autres clients, en utilisant des balises d'entités dans les entêtes If-Match dans toute entête de requête de modification des ressources.

Les gestionnaires d'information peuvent essayer de contrôler les écrasements en implémentant des procédures du côté client exigeant le verrouillage avant de modifier des ressources WebDav .

7 Verrou d'écriture

Cette section décrit la sémantique propre au verrou d'écriture. Le verrou d'écriture est une instance spécifique du type verrou ; il est le seul type de verrou décrit dans cette sépcification.

7.1 méthodes restreintes par les verrous d'écriture

Un verrou d'écriture DOIT contrôler qu'un demandeur n'ayant pas le verrou ne peut exécuter avec succès aucune des méthodes PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, DELETE , ou MKCOL sur la ressource verrouillée. Toutes les autres méthodes courantes, en particulier GET , fonctionnent indépendamment de ce verrou.

Remarquez, toutefois, que lorsque des nouvelles méthodes seront créées il sera nécessaire de spécifier comment elles devront se comporter vis à vis du verrou d'écriture.

7.2 Verrous d'écriture et marqueurs de verrous

Une demande réussie pour obtenir un verrou d'écriture DOIT se traduire par la génération d'un marqueur de verrou unique associé au demandeur. Aussi, si cinq demandeurs ont un verrou d'écriture partagé sur la même ressource il y aura cinq marqueurs de verrous, un par demandeur.

7.3 Verrous d'écriture et propriétés

Alors que ceux qui n'ont pas posé de verrou d'écriture ne peuvent pas modifier les propriétés d'une ressource, il est cependant toujours possible que les valeurs des propriétés vivantes soient changées, même quand elles sont verrouillées, à cause des exigences de leurs modèles.

Seules les propriétés mortes et vivantes dont les spécifications les soumettent au contrôle des verrous sont garanties de ne pas changer quand un verrou d'écriture est posé.

7.4 Verrous d'écriture et ressources nulles

Il est possible de positionner un verrou d'écriture sur une ressource nulle afin d'en bloquer le nom.

Une ressource nulle bloquée en écriture, connue sous le nom de ressource nulle verrouillée, DOIT retourner une erreur type 404 (Pas trouvée) ou 405 (méthode interdite) à toute méthode HTTP/1.1 ou DAV à l'exception des méthodes PUT, MKCOL, OPTIONS, PROPFIND, LOCK , et UNLOCK . Une ressource nulle verrouillée DOIT apparaître comme un membre de la collection parente dont elle fait partie. De plus, la ressource nulle verrouillée DOIT être équipée de toutes les propriétés obligatoires de DAV . La plupart de ces propriétés, comme par exemple toutes les propriétés de type get* , n'auront aucune valeur puisqu'une ressource nulle verrouillée ne supporte pas la méthode GET . Les ressources nulles verrouillées DOIVENT être équipées des propriétés lockdiscovery et supportedlock .

Jusqu'au moment où l'une des méthodes PUT ou MKCOL est exécutée avec succès sur la ressource nulle verrouillée, celle-là DOIT rester dans son état de ressource nulle verrouillée. Toutefois, dès qu'une des méthodes PUT ou MKCOL est exécutée avec succès, alors la ressource nulle verrouillée cesse d'être dans l'état nul-verrouillé.

Si la ressource est déverrouillée, quelque en soit la raison, sans qu'un PUT, MKCOL , ou toute méthode similaire n'ait été exécutée avec succès, alors la ressource DOIT retourner à son état nul.

7.5 Verrous d'écriture et collections

Un verrou d'ériture sur une collection, qu'il ait été créé par une requête de verrouillage de type "Depth: 0 " ou "Depth: infinity ", empêche le rajout ou le retrait d'URI membres de la collection par d'autres demandeurs que les propritaires des verrous. En conséquence, quand un demandeur réalise une requête PUT ou POST pour créer une nouvelle ressource sous une URI qui se trouve être un membre interne d'une collection verrouillée en écriture et pour maintenir la cohérence de l'espace de noms HTTP , ou qu'il souhaite réaliser un DELETE pour retirer une ressource dont l'URI est une URI d'un membre interne d'une collection protégée en écriture, alors cette requête DOIT échouer si le demandeur n'est pas propriétaire d'un verrou d'écriture au niveau de la collection.

Toutefois, si une demande de verrou d'écriture est faite sur une collection contenant des URI membres qui s'appliquent à des ressources en cours de verrouillage et d'une manière qui soit conflictuelle avec le verrou d'écriture, alors la demande DOIT échouer et retourner le code d'état 423 (Verrouillé).

Si le propriétaire d'un verrou rajoute l'URI d'une ressource en tant que membre interne d'une collection verrouillée alors cette nouvelle ressource DOIT être automatiquement rajoutée au verrou. Cela est le seul mécanisme qui permet de rajouter une ressource à un verrou d'écriture. Aussi, par exemple, si la collection /a/b/ est verrouillée en écriture est que la ressource /c est déplacée pour devenir /a/b/c alors la ressource /a/b/c sera rajoutée au verrou d'écriture.

7.6 Verrous d'écriture et entête de requête If

Si il n'est pas obligatoire d'avoir un agent utilisateur pour connaître l'existence d'un verrou quand on demande l'exécution d'une opération sur une ressource verrouillée, le scénario suivant peut se produire. Un programme A, exécuté par un utilisateur A, pose un verrou d'écriture sur une ressource. Un programme B, également exécuté par l'utilisateur A, n'a pas la connaissance du verrou posé par le programme A, exécute un PUT sur la ressource verrouillée. Dans ce scénario, le PUT est réalisé avec succès parce que les verrous sont associés à un même demandeur, pas un programme. Et donc le programme B, parce qu'il est activé par le même certificat de demandeur que A, est autorisé à faire le PUT . Toutefois, si le programme B avait eu connaissance du verrou, il n'aurait pas écrasé la ressource, préférant à la place présenter une boîte de dialogue annonçant le conflit à l'utilisateur. A cause de ce scénario, on a besoin d'un mécanisme pour empêcher que des programmes différents ignorent accidentellement les verrous posés par d'autres programmes ayant les mêmes privilèges.

Afin d'empêcher ces collisions, un marqueur de verrou DOIT être posé par un demandeur autorisé dans l'entête If de toute ressource verrouillée pouvant réagir à des méthodes ou sinon la méthode DOIT échouer. Par exemple, si une ressource doit être déplacée et que la source et la destination sont toutes les deux verrouillées alors deux marqueurs de verrous doivent être soumis, l'un pour la source et l'autre pour la destination.

7.6.1 Exemple - verrou d'écriture

>>Requête

COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
If: <http://www.ics.uci.edu/users/f/fielding/index.html>
(<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)

>>Réponse

HTTP/1.1 204 No Content

Dans cet exemple, même si la source et la destination sont toutes les deux verrouillées, un seul marqueur de verrou doit être soumis, celui pour le verrou sur la destination. Cela parce que la source n'est pas modifiée par l'ordre COPY , et par conséquent, n'est pas concernée par le verrou d'écriture. Dans cet exemple, l'authentification de l'agent utilisateur est déjà intervenue via un mécanisme en dehors du périmètre concerné par le protocole HTTP , c'est à dire dans la couche de transport sous-jacente.

7.7 Verrous d'écritre et méthode COPY/MOVE

L'exécution de la méthode COPY NE DOIT PAS dupliquer les verrous d'écriture actifs sur la source. Toutefois, comme il a été noté précédemment, si l'ordre COPY copie la ressource dans une collection qui, elle, est verrouillée avec l'option "Depth: infinity ", alors la ressource sera ajoutée au verrou.

Une requête MOVE appliquée avec succès sur une ressource ayant un verrou d'écriture NE DOIT PAS déplacer le verrou d'écriture avec la ressource. Toutefois, la ressource est sujette à être rajoutée à un verrou déjà existant au niveau de la destination, comme cela est spécifié dans la section 7. Par exemple, si le MOVE fait que la ressource devient un enfant d'une collection qui est verrouillée avec l'option "Depth: infinity", alors la ressource sera ajoutée au verrou déjà existant au niveau de la collection. De plus, si une ressource verrouillée avec l'option "Depth: infinity " est déplacée vers une destination qui se trouve a l'intérieur de la portée de ce même verrou (par exemple, à l'intérieur de l'arbre d'espace de noms couvert par le verrou), la ressource déplacée sera à nouveau rajoutée au verrou. Dans ces deux exemples, et comme il est spécifié dans la section 7.6, une entête If contenant un marqueur de verrou doit être soumise tant pour la source que pour la destination.

7.8 Rafraîchissement des verrous d'écriture

Un client N'A PAS A soumettre deux fois de suite une même requête d'écriture. Remarquez qu'un client sait toujours qu'il est en train de soumettre un même verrou pour la deuxième fois puisqu'il doit inclure le marqueur de verrou dans l'entête If de sa requête afin de pouvoir soumettre sa requête sur une ressource qu'il sait être déjà vérouillée.

Toutefois, un client peut soumettre une méthode LOCK avec une entête If mais sans corps. Cette forme de LOCK DOIT être uniquement utilisée pour "rafraichir" un verrou. Cela signifie, au minimum, que tout système de temporisation associé au verrou DOIT être réinitialisé.

Un serveur peut très bien retourner une entête de dépassement de temps (timeout) avec un rafraîchissement de verrou différent de l'entête de dépassement de temps retournée quand le verrou fut initialement créé. De plus, des clients peuvent soumettre des entêtes de dépassement de temps de valeur arbitraire dans leurs requêtes de rafraîchissement de verrou.Les serveurs, comme toujours, peuvent ignorer les entêtes de dépassement de temps soumises par leurs clients.

Si une erreur est reçue en réponse à une requêtre de rafraîchissement de LOCK le client DOIT garantir que le verrou n'a pas déjà été rafraichi.

8 Méthodes HTTP pour la rédaction distribuée

Les nouvelles méthodes HTTP décrites ci-après utilisent XML comme format de requête et de réponse. Tous les clients et les ressources conformes à DAV DOIVENT utiliser des parsers XML conformes à la norme [REC-XML]. Tout le XML utilisé que ce soit dans les requêtes ou dans les réponses DOIT être, au minimum, bien formé. Si un serveur reçoit dans une requête des données XML pas bien formées il DOIT rejeter la totalité de la requête avec un code 400 (mauvaise requête). Si un client reçoit dans une réponse des données XML mal formées, il NE DOIT PAS supposer quoi que ce soit concernant le résultat à retourner par la méthode et DOIT se contenter de considérer que le serveur ne fonctionne pas bien.

8.1 La méthode PROPFIND

La méthode PROPFIND permet de récupérer tant les propriétés de la ressource identifiée par l'URI requête si la ressource n'a aucun membre interne, que celles de la ressource identifiée par l'URI requête et ses ressources membres internes si la ressource est une collection qui a des URIs de membres internes. Toutes les ressources conformes à DAV DOIVENT supporter la méthode PROPFIND et l'élément XML propfind (section 12.14) ainsi que tous les éléments XML définis pour être utilisés avec cet élément.

Un client peut soumettre une entête Depth qualifiée par une des valeurs "0 ", "1 " ou "infinity " quand la méthode PROPFIND est appliquée à une ressource de type collection contenant des URI de membres internes. Les serveurs conformes à DAV DOIVENT supporter les comportements correspondant aux valeurs "0 ", "1 " et "infinity ". Par défaut, une méthode PROPFIND n'ayant pas entête Depth DOIT agir comme si la valeur "Depth: infinity " avait été utilisée.

Un client peut utiliser l'élément XML propfind dans le corps de la méthode request pour préciser l'information recherchée. Il est ainsi possible de ne demander à obtenir soit que les valeurs de certaines propriétés particulières, soit toutes les valeurs d'une propriété, ou encore une liste de noms de propriétés de la ressource. Un client peut choisir de ne soumettre qu'une requête sans corps. Une requête de type PROPFIND avec un corps vide DOIT être traitée comme une demande de récupération de tous les noms et de toutes les valeurs de toutes les propriétés de la ressource.

Tous les serveurs DOIVENT être capable de retourner une réponse dont le contenu soit de type text/xml ou application/xml et dans laquelle l'élément XML multistatus sera utilisé pour y décrire les résultats obtenus dnas la recherche des différentes propriétés.

Si un problème survient dans la lecture d'une propriété, alors une erreur spécifique DOIT être incluse dans la réponse. Une requête qui porte sur l'obtention de la valeur d'une propriété qui n'existe pas est un cas d'erreur qui DOIT être relevé. Si la réponse est fournie sous la forme de l'élément XML multistatus , il faut générer un élément XML response contenant le code d'état 404 (Pas Trouvé).

En conséquence, l'élément XML multistatus d'une ressource de type collection ayant des URI membres DOIT avoir, en fonction de la profondeur depth spécifiée, un élément XML response pour chacune des URI membres de la collection. Chaque élément XML response DOIT contenir l'élément XML href qui donne l'URI de la resource à laquelle se rapporte les propriétés de l'élément XML prop. Les résultats de la méthode PROPFIND appliquée à une ressource de type collection ayant des URI de membres internes sont retournés sous la forme d'une liste plate dont l'ordre des entrées n'est pas significative.

Dans les cas allprop et propname , si un demandeur n'est pas autorisé à savoir si une propriété particulière existe alors elle DOIT être exclue de la réponse en la rendant invisible.

Les résultats de cette méthode NE DOIVENT PAS être mis dans le cache.

8.1.1 Exemple - Obtenir des propriétés nommées

>>Requête

PROPFIND /file HTTP/1.1
Host: www.foo.bar
Content-type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D="DAV:">
     <D:prop xmlns:R="http://www.foo.bar/boxschema/">
          <R:bigbox/>
          <R:author/>
          <R:DingALing/>
          <R:Random/>
     </D:prop>
   </D:propfind>

>>Réponse

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:">
     <D:response>
          <D:href>http://www.foo.bar/file>
          <D:propstat>
               <D:prop xmlns:R="http://www.foo.bar/boxschema/">
                    <R:bigbox>
                         <R:BoxType>Box type A</R:BoxType>
                    </R:bigbox>
                    <R:author>
                         <R:Name>J.J. Johnson</R:Name>
                    </R:author>
               </D:prop>
               <D:status>HTTP/1.1 200 OK</D:status>
          </D:propstat>
          <D:propstat>
               <D:prop><R:DingALing/><R:Random/></D:prop>
               <D:status>HTTP/1.1 403 Forbidden</D:status>
               <D:responsedescription> The user does not have access to the DingALing property.
               </D:responsedescription>
          </D:propstat>
     </D:response>
     <D:responsedescription> There has been an access violation error.</D:responsedescription>    </D:multistatus>

Dans cette exemple, la méthode PROPFIND est appliquée à une ressource qui n'est pas une collection, à savoir le fichier http://www.foo.bar/file. L'élément XML propfind précise le nom de quatre propriétés dont on cherche à obtenir les valeurs. Dans ce cas, seulement deux des valeurs sont retournées, puisque le demandeur qui émet cette requête n'a pas les droits d'accès suffisants pour voir les troisième et quatrième propriétés.

8.1.2 Exemple - Utilisation de allprop pour obtenir toutes les propriétés

>>Requête

PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Depth: 1
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D="DAV:">
     <D:allprop/>
   </D:propfind>

>>Réponse

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:">
     <D:response>
          <D:href>http://www.foo.bar/container/>
          <D:propstat>
               <D:prop xmlns:R="http://www.foo.bar/boxschema/">
                    <R:bigbox>
                         <R:BoxType>Box type A</R:BoxType>
                    </R:bigbox>
                    <R:author>

                         <R:Name>Hadrian</R:Name>
                    </R:author>
                    <D:creationdate>
                         1997-12-01T17:42:21-08:00
                    </D:creationdate>
                    <D:displayname>
                         exemple collection
                   </D:displayname>
                    <D:resourcetype><D:collection/></D:resourcetype>
                    <D:supportedlock>
                         <D:lockentry>
                              <D:lockscope><D:exclusive/></D:lockscope>
                              <D:locktype><D:write/></D:locktype>
                         </D:lockentry>
                         <D:lockentry>
                              <D:lockscope><D:shared/></D:lockscope>
                              <D:locktype><D:write/></D:locktype>
                         </D:lockentry>
                    </D:supportedlock>
               </D:prop>
               <D:status>HTTP/1.1 200 OK</D:status>
          </D:propstat>
     </D:response>
     <D:response>
          <D:href>http://www.foo.bar/container/front.html>
          <D:propstat>
               <D:prop xmlns:R="http://www.foo.bar/boxschema/">
                    <R:bigbox>
                         <R:BoxType>Box type B</R:BoxType>
                    </R:bigbox>
                    <D:creationdate>
                         1997-12-01T18:27:21-08:00
                    </D:creationdate>
                    <D:displayname>
                         exemple HTML resource
                    </D:displayname>
                    <D:getcontentlength>
                         4525
                    </D:getcontentlength>
                    <D:getcontenttype>
                         text/html
                    </D:getcontenttype>
                    <D:getetag>
                         zzyzx
                    </D:getetag>
                    <D:getlastmodified>
                         Monday, 12-Jan-98 09:25:56 GMT
                    </D:getlastmodified>
                    <D:resourcetype/>
                    <D:supportedlock>
                         <D:lockentry>
                              <D:lockscope><D:exclusive/></D:lockscope>
                              <D:locktype><D:write/></D:locktype>
                         </D:lockentry>
                         <D:lockentry>
                              <D:lockscope><D:shared/></D:lockscope>
                              <D:locktype><D:write/></D:locktype>
                         </D:lockentry>
                    </D:supportedlock>
               </D:prop>
               <D:status>HTTP/1.1 200 OK</D:status>
          </D:propstat>
     </D:response>
   </D:multistatus>

Dans cette exemple, la méthode PROPFIND a été invoquée sur la ressource http://www.foo.bar/container/ avec une entête Depth de 1 , signifiant que la requête s'applique à la ressource et ses enfants de premier niveau, et l'élément XML propfind contient l'élément XML allprop , ce qui signifie que la requête doit retourner le nom et la valeur de toutes les propriétés de chaque ressource.

La ressource http://www.foo.bar/container/ possède les six propriétés suivantes :

  1. http://www.foo.bar/boxschema/bigbox,
  2. http://www.foo.bar/boxschema/author,
  3. DAV:creationdate ,
  4. DAV:displayname,
  5. DAV:resourcetype ,
  6. DAV:supportedlock .

Les quatre dernières sont spécifiques à WebDAV, et sont définies dans la section 13. Comme la méthode GET n'est pas supportée par cette ressource, les propriétés get* (comme par exemple getcontentlength ) ne sont pas utilisables sur cette ressource. Les propriétés spécifiques à DAV attestent que "container " fut créé le 1er décembre 1997, à 5:42:21 de l'après midi, dans un fuseau horaire à 8 heures ouest de GMT (creationdate), a le nom "exemple collection " (displayname ), un type de ressource collection (resourcetype ), et supports les verrous d'écriture exclusifs et partagés (supportedlock ).

La ressource http://www.foo.bar/container/front.html possède les neuf propriétés suivantes :

  1. http://www.foo.bar/boxschema/bigbox (un autre cas d'instance du type de propriété "bigbox "),
  2. DAV:creationdate,
  3. DAV:displayname,
  4. DAV:getcontentlength,
  5. DAV:getcontenttype,
  6. DAV:getetag,
  7. DAV:getlastmodified,
  8. DAV:resourcetype ,
  9. DAV:supportedlock .

Les propriétés spécifiques à DAV attestent que "front.html " fut créé le 1er décembre 1997, à 6:27:21 de l'après-midi, dans un fuseau horaire de 8 heures à l'ouest de GMT (creationdate ), a le nom de "exemple HTML resource " (displayname ), a un contenu de 4525 octets de long (getcontentlength ), a le type MIME "text/html " (getcontenttype ), a une balise d'entité "zzyzx " (getetag ), fut modifié en dernier le lundi 12 janvier 1998 à 09:25:56 GMT (getlastmodified ), a un type de ressource vide, signifiant qu'il ne s'agit pas d'une collection (resourcetype ), et accepte les deux types de verrous d'écriture : exclusif et partagé (supportedlock ).

8.1.3 Exemple - Utilisation de propname pour obtenir les noms de toutes les propriétés

>>Requête

PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
   <propfind xmlns="DAV:">
     <propname/>
   </propfind>

>>Réponse

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <multistatus xmlns="DAV:">
     <response>
          <href>http://www.foo.bar/container/>
          <propstat>
               <prop xmlns:R="http://www.foo.bar/boxschema/">
                    <R:bigbox/>
                    <R:author/>
                    <creationdate/>
                    <displayname/>
                    <resourcetype/>
                    <supportedlock/>
               </prop>
               <status>HTTP/1.1 200 OK</status>
          </propstat>
     </response>
     <response>
          <href>http://www.foo.bar/container/front.html>
          <propstat>
               <prop xmlns:R="http://www.foo.bar/boxschema/">
                    <R:bigbox/>
                    <creationdate/>
                    <displayname/>
                    <getcontentlength/>
                    <getcontenttype/>
                    <getetag/>
                    <getlastmodified/>
                    <resourcetype/>
                    <supportedlock/>
               </prop>
               <status>HTTP/1.1 200 OK</status>
          </propstat>
     </response>
   </multistatus>

Dans cette exemple, PROPFIND est appliquée à la ressource collection http://www.foo.bar/container/, et l'élément XML propfind contient l'élément XML propname , signifiant que les noms de toutes les propriétés doivent être retournés. Puisqu'il n'y a aucune précision de Depth dans l'entête, la valeur par défaut "infinity " est appliquée et tous les noms des propriétés de la collection mais également de tous ses descendants doivent être retournés.

Ainsi, on trouve que dans l'exemple précédent, la ressource http://www.foo.bar/container/ possède six propriétés :

  1. http://www.foo.bar/boxschema/bigbox,
  2. http://www.foo.bar/boxschema/author,
  3. DAV:creationdate,
  4. DAV:displayname,
  5. DAV:resourcetype ,
  6. DAV:supportedlock .

La ressource http://www.foo.bar/container/index.html, membre de la collection "enveloppe", possède neuf propriétés,

  1. http://www.foo.bar/boxschema/bigbox,
  2. DAV:creationdate,
  3. DAV:displayname,
  4. DAV:getcontentlength,
  5. DAV:getcontenttype,
  6. DAV:getetag,
  7. DAV:getlastmodified,
  8. DAV:resourcetype ,
  9. DAV:supportedlock .

Cette exemple montre également l'utilisation de la portée des espaces de noms de XML, et de l'espace de noms par défaut. Puisque l'attribut "xmlns" n'a pas de lettre de raccourci (préfixe) explicite, l'espace de nom par défaut s'applique à tous les éléments englobés. Par conséquent, tous les éléments qui ne font pas explicitement état de l'espace de noms auquel ils appartiennent sont membres du schéma de données de l'espace de noms "DAV: ".

8.2 La méthode PROPFIND

La méthode PROPPATCH traite des instructions spécifiées dans le corps de la requête pour assigner et/ou supprimer des propriétés définies sur la ressource identifiée par l'URI requête.

Toutes les ressources conformes à DAV DOIVENT supporter la méthode PROPPATCH et DOIVENT traiter des instructions qui sont spécifiées par les éléments XML propertyupdate, set , et remove du schéma de données de DAV. L'exécution des consignes dans cette méthode est, bien sûr, soumise aux restrictions des contrôles d'accès. Les ressources conformes à DAV DOIVENT supporter l'initialisation de n'importe quelle propriété potentiellement morte.

La corps du message de requête d'une méthode PROPPATCH DOIT contenir l'élément XML propertyupdate . Le traitement des instructions DOIT se faire dans l'ordre des instructions reçues (c'est à dire de haut en bas). Les instructions DOIVENT être soit toutes exécutées soit ne pas être exécutées du tout. Ainsi, si une erreur survient pendant le traitement alors toutes les instructions déjà exécutées DOIVENT être annulées et un code d'erreur approprié doit être retourné. Le traitement détaillé des instructions peut être trouvé dans la définition des instructions set et remove dans la section 12.13.

8.2.1 Codes d'états à utiliser avec des méthodes à états multiples 207

Les exemples suivant sont des codes de réponses qu'on s'attend à recevoir dans les réponses aux méthodes de type 207 (états multiples). Remarquez toutefois, que tant que cela n'est pas explicitement prohibé, toute code de retour des séries 2/3/4/5xx peuvent être utilisés dans une réponse de type 207 (états multiples).

200 (OK) - La commande a réussi.Comme il peut y avoir une série de commandes set et remove dans un corps de requête, un code de retour 201 (Créé) semble inaproprié.

403 (Interdit) - Le client, pour une raison que le serveur choisit de na pas dévoiler, ne peut pas modifier l'une des propriétés.

409 (Conflit) - Le client a transmis une valeur dont la sémantique est inappropriée pour la propriété visée. Cela comprend par exemple les tentatives d'initialisation des propriétés qui sont en lecture seule.

423 (Verrouillé) - La ressource spécifiée est verrouillée et le client, soit n'est pas le propriétaire du verrou, soit le type de verrou requiert qu'un marqueur de verrou soit soumis et que cela n'a pas été fait par le client.

507 (Mémoire insuffisante) - Le serveur n'a pas assez de mémoire pour enregistrer la propriété.

8.2.2 Exemple - PROPPATCH

>>Requête

PROPPATCH /bar.html HTTP/1.1
Host: www.foo.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propertyupdate xmlns:D="DAV:"    xmlns:Z="http://www.w3.com/standards/z39.50/">
     <D:set>
          <D:prop>
               <Z:authors>
                    <Z:Author>Jim Whitehead</Z:Author>
                    <Z:Author>Roy Fielding</Z:Author>
               </Z:authors>
          </D:prop>
     </D:set>
     <D:remove>
          <D:prop><Z:Copyright-Owner/></D:prop>
     </D:remove>
   </D:propertyupdate>

>>Réponse

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:"    xmlns:Z="http://www.w3.com/standards/z39.50">
     <D:response>
          <D:href>http://www.foo.com/bar.html>
          <D:propstat>
               <D:prop><Z:Authors/></D:prop>
               <D:status>HTTP/1.1 424 Failed Dependency</D:status>
          </D:propstat>
          <D:propstat>
               <D:prop><Z:Copyright-Owner/></D:prop>
               <D:status>HTTP/1.1 409 Conflict</D:status>
          </D:propstat>
          <D:responsedescription> Copyright Owner can not be deleted or    altered.</D:responsedescription>
     </D:response>
   </D:multistatus>

Dans cet exemple, le client demande au serveur d'initialiser la valeur de la propriété http://www.w3.com/standards/z39.50/Authors, et de retirer la propriété http://www.w3.com/standards/z39.50/Copyright-Owner. Mais comme la propriété Copyright-Owner s'avère être impossible à retirer, aucune modification de propriété n'est prise en compte par le serveur. Le code de retour 424 (Echec de dépendance) pour la propriété Authors permet de savoir que cette action aurait été réussie si elle n'en n'avait pas été empêchée par le conflit sur la propriété Copyright-Owner .

8.3 Méthode MKCOL

La méthode MKCOL est utilisée pour créer une nouvelle collection. Toutes les ressources conformes à DAV DOIVENT supporter la méthode MKCOL .

8.3.1 Requête

MKCOL crée une nouvelle ressource de type collection à l'emplacement spécifié par l'URI requête. Si la ressource identifiée par l'URI requête n'est pas nulle, alors le MKCOL DOIT échouer. Pendant le traitement de MKCOL , un serveur DOIT faire en sorte que l'URI requête devienne un membre de sa collection père, la seule exception étant le cas où l'URI requête est elle-même "/". Dans tous les autres cas, si la collection parente n'existe pas, alors la méthode MKCOL DOIT échouer. Quand MKCOL crée une nouvelle ressource de type collection, tous les ancêtres DOIVENT préalabalement exister, sinon, la méthode DOIT échouer et retourner le code d'état 409 (Conflit). Par exemple, si une demande de création de la collection /a/b/c/d/ est faite, et que ni /a/b/ ni /a/b/c/ existent, alors la requête DOIT échouer.

Quand MKCOL est invoquée sans corps de requête, la collection nouvellement créée DEVRAIT n'avoir aucun membre.

Le message d'une requêt MKCOL peut contenir un corps. Le comportement d'une requête MKCOL ayant un corps est limité à la création de collections, de membres d'une collection, de corps de membres et/ou de propriétés sur les collections et leurs membres. Si le serveur reçoit une entité de type requête MKCOL qu'il ne supporte pas ou qu'il ne comprend pas il DOIT retourner le code d'état 415 (Type de média non supporté). Le comportement exact que doit avoir la méthode MKCOL en fonction des différents types de média n'est pas défini dans ce document, et sera spécifié dans d'autres documents.

8.3.2 Codes d'états

Les codes de retour renvoyés par la méthode MKCOL NE DOIVENT PAS être stockés dans le cache.

201 (Créée) - La collection ou la ressource structurée a été correctement et complètement créée.

403 (Interdit) - Ce code indique qu'au moins une des deux conditions est vérifiée :

  1. le serveur n'autorise pas la création de collections à l'emplacement indiqué dans son espace de noms,
  2. la collection parente de l'URI requête existe mais ne peut recevoir de membres.

405 (méthode non autorisée) - MKCOL peut seulement être exécuté sur un ressource détruite ou inexistante.

409 (Conflit) - Une collection ne peut pas être fabriquée à l'URI requête spécifiée tant que au moins une collection intermédiaire n'aura pas été créée.

415 (Type de média non supporté)- Le serveur ne supporte pas le type de requête contenu dans le corps.

507 (Mémoire insuffisante) - Il n'y a pas assez d'espace pour que la ressource puisse enregistrer son état après exécution de la méthode.

8.3.3 exemple - MKCOL

Cette exemple crée une collection nomée /webdisc/xfiles/ sur le serveur www.server.org.

>>Requête

MKCOL /webdisc/xfiles/ HTTP/1.1
Host: www.server.org

>>Réponse

HTTP/1.1 201 Created

8.4 Méthodes GET et HEAD appliquées à des collections

La sémantique de la méthode GET est inchangée quand elle est appliquée à une collection, puisque la méthode GET est définie ainsi, "extrait toute information (sous la forme d'une entité) identifiée par l'URI requête" [RFC2068]. Quand la méthode GET est appliquée à une collection, elle peut retourner le contenu d'une ressource "index.html", ou encore une représentation humainement lisible du contenu de la collection, ou d'autres résultats encore. Par conséqsuent, il est tout à fait possible que le résultat d'un GET appliqué à une collection aura aucun rapport avec les membres appartenant à cette collection.

De la même manière, la définition de la méthode HEAD étant la même que celle du GET à l'exception du corps du message de réponse, retiré dans le cas de la méthode HEAD, la sémantique de HEAD est inchangée quand cette méthode est appliquée à des ressources de type collection.

8.5 La méthode POST appliquée à des collections

Puisque par définition la fonction réellement réalisée par POST est déterminée par le serveur et dépend souvent de la ressource particulière à laquelle elle est appliquée, le comportement de POST quand cette méthode est appliquée à des collections ne peut pas être modifié dans sa signification puisque celui-là est largement indéfini. En conséquence la sémantique de la méthode POST est inchangée quand elle s'applique à une collection.

8.6 Méthode DELETE

8.6.1 Méthode DELETE appliquée à des ressources autres que des collections

Si la méthode DELETE est appliquée à une ressource qui n'est pas une collection et dont l'URI est un membre interne d'une ou plusieurs collections, alors un serveur DOIT, pendant l'exécution du DELETE, retirer toutes les URI de la ressource identifiée par l'URI requête des collections qui la contiennent comme membre.

8.6.2 Méthode DELETE appliquée à des collections

La méthode DELETE appliquée à une collection DOIT agir comme si l'entête "Depth: infinity" était appliquée. Vis à vis de la méthode DELETE, un client NE DOIT soumettre AUCUNE autre valeur que infinity pour l'entête Depth.

DELETE donne l'instruction de destruction de la collection spécifiée à l'URI requête ainsi que de la totalité des ressources identifiées par ses membres internes.

Si l'une quelconque des ressources identifiées par l'URI d'un membre de la collection ne peut être détruite, alors aucun des ancêtres du membre NE DOIT être détruit, cela afin de maintenir la cohésion de l'espace de noms.

Toute entête inclue avec l'ordre DELETE DOIT être appliquée lors du traitement de chacune des ressources à détruire.

Quand la méthode DELETE est terminée, elle DOIT avoir restituée un espace de noms régulier.

Si une erreur survient avec une ressource autre que celle identifiée par l'URI requête, alors la réponse DOIT avoir la valeur 207 (états multiples). Les erreurs de type 424 (Echec de dépendance) NE DEVRAIENT PAS être dans un 207 (états multiples). Elle peuvent être mises de côté en toute sécurité parce que le client saura que les ancêtres d'une ressource n'ont pu être détruits quand le client reçoit une erreur concernant la progéniture d'un ancêtre. De plus, les erreurs 204 (Pas de contenu) NE DEVRAIENT PAS être retournés en 207 (états multiples). La raison de cette interdiction est que le code 204 (Pas de contenu) est le code de retour par défaut en cas de succès.

8.6.2.1 Exemple - DELETE

>>Requête

DELETE /container/ HTTP/1.1
Host: www.foo.bar

>>Réponse

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <d:multistatus xmlns:d="DAV:">
     <d:response>
          <d:href>http://www.foo.bar/container/resource3</d:href>
          <d:status>HTTP/1.1 423 Locked</d:status>
     </d:response>
   </d:multistatus>

Dans cet exemple, la tentative de destruction de http://www.foo.bar/container/resource3 échoue parce que la ressource est verrouillée, et aucun marqueur de verrou n'a été soumis avec la requête. En conséquence, la tentative de destruction de http://www.foo.bar/container/ échoue aussi. Ainsi, le client est informé que la tentative de destruction de http://www.foo.bar/container/ a échoué puisque le parent ne peut pas être détruit tant que ses enfants ne le sont pas. Aucune entête Depth n'ayant été incluse, la valeur par défaut infinity a été prise en compte puisque la méthode est appliquée à une collection.

8.7 Méthode PUT

8.7.1 Méthode PUT pour des ressources autres que des collections

Un PUT réalisé sur une ressource existante remplace l'entité que la ressource retourne en réponse à un GET. Les propriétés définies sur la ressource peuvent être recalculées pendant le traitement du PUT mais ne sont pas autrement modifiées. Par exemple, si un serveur reconnait le type de contenu du corps de la requête, il peut être capable d'en extraire automatiquement l'information intéressante à exposer en tant que propriété.

Un PUT dont le résultat serait la création d'une ressource sans collection parent appropriée DOIT échouer et retourner un code 409 (Conflit).

8.7.2 Méthode PUT appliquée à des collections

Comme il est défini dans dans la spécification HTTP/1.1 [RFC2068], la méthode PUT "impose que l'entité envoyée soit stockée sous l'URI requête transmise". Puisque la soumission d'une entité de type collection pourrait entraîner implicitement la création ou la destruction de ressources, cette spécification ne définit intentionnellement aucun format pour la création de collection via la méthode PUT. C'est la méthode MKCOL qui est définie dans cette spécificaiton pour la création de collections.

Quand l'opération PUT crée une nouvelle ressource qui n'est pas une collection, tous ses ancêtres DOIVENT préalablement exister. Si tous les ancêtres n'existent pas, la méthode DOIT échouer et retourner un code 409 (Conflit). Par exemple, si la ressource /a/b/c/d.html doit être créée et que /a/b/c/ n'existe pas, alors la requête DOIT échouer.

8.8 La méthode COPY

La méthode COPY crée une copie de la ressource source identifiée par l'URI requête, dans la ressource de destination, identifiée par l'URI qui se trouve dans l'entête Destination. L'entête Destination DOIT être présente. Le comportement exact de la méthode COPY dépend du type de ressource source copiée.

Toute ressource conforme à WebDav DOIT supporter la méthode COPY. Toutefois, le support de la méthode COPY ne garantit pas qu'il soit réellement possible de copier la ressource. Par exemple, des ressources pourtant présentes sur le même serveur peuvent être contrôlées par des programmes distincts. En conséquence, il pourrait ne pas être possible de copier une ressource à un emplacement apparemment sur le même serveur.

8.8.1 Méthode COPY pour des ressources HTTP/1.1

Quand la ressource source n'est pas une collection, le résultat de la méthode COPY est la création d'une nouvelle ressource à un emplacement de la destination avec un état et un comportement le plus proche possible de ceux de la ressource source. Après l'exécution réussie d'un COPY, toutes les propriétés de la ressource source DOIVENT avoir été copiées sur la ressource de destination, en étant toutefois sujettes à des modifications de leurs entêtes et d'éléments XML, respectant en cela les règles de copiage des propriétés. Puisque l'environnement de la destination peut être différent de celui de la source pour des raisons qui sont indépendantes des possibilités de contrôle du serveur, tel que l'absence d'une ressource pourtant nécessaire au bon fonctionnement de l'opération, il peut arriver que l'ensemble des comportements de la ressource ne puisse être copié dans la destination cible. Les altérations consécutives de la ressource de destination ne modifiera pas la ressource source. Les altérations consécutives de la ressource source ne modifieront pas la ressource de destination.

8.8.2 Méthode COPY appliquée à des propriétés

La section suivante définie comment la méthode COPY s'applique aux propriétés d'une ressource.

Les propriétés vivantes DEVRAIENT être dupliquées comme propriétés vivantes en conservant au niveau de la ressource de destination le même comportement que celui qu'elles ont sur la ressource source. Si une propriété ne peut pas être copiée en conservant son comportement, alors sa valeur DOIT être dupliquée, octet à octet, dans une propriété morte de nom identique, sur la ressource de destination et en tenant compte des conditions précisées par l'éléments XML propertybehavior.

L'élément XML propertybehavior peut spécifier que les propriétés sont copiées de la meilleure manière possible, que, soit toutes les propriétés vivantes SONT copiées avec succès soit la méthode DOIT échouer, ou que, soit la copie d'une liste spécifiée de propriétés vivantes EST être réussie soit la méthode DOIT échouer. L'élément XML propertybehavior est défini à la section 12.12.

8.8.3 Méthode COPY appliquée à des collections

La méthode COPY appliquée à une collection sans avoir précisé la valeur de l'entête Depth DOIT agir en prenant comme valeur par défaut "infinity". Les valeurs qu'un client a le droit de soumettre dans l'entête depth de la méthode COPY sont "0" ou "infinity". Les serveurs conformes DAV DOIVENT supporter ces deux valeurs.

La valeur infinity signifie que la collection d'origine, identifiée par l'URI requête, doit être copiée à l'emplacement spécifié par l'URI fournie dans l'entête Destination, et que toutes les ressources membres internes de la collection d'origine, sur tous ses niveaux de profondeur, doivent être récursivement copiées à l'emplacement de la ressource de destination.

Une COPY avec "Depth: 0" ne fait que signifier que la collection d'origine et ses propriétés doivent être copiés mais pas les ressources identifiées par ses URI de membres internes.

Toute entête spécifiée dans une requête COPY DOIT être appliquée à chaque ressource copiée, pendant sa copie, à l'exception de l'entête Destination.

L'entête Destination ne fait que spécifier l'URI "de destination" de l'URI requête. Quand on l'applique aux membres de la collection identifiée par l'URI requête, la valeur de Destination est modifiée pour refléter la position relative des ressources dans la hiérarchie copiée.

Ainsi : Soit la resource /a/ à laquelle on applique les valeurs http://fun.com/ comme valeur d'entête Host et http://fun.com/b/ pour valeur d'entête Destination, alors quand la ressource http://fun.com/a/c/d est copiée, la Destination qui DOIT être utilisée est http://fun.com/b/c/d.

Quand l'exécution de la méthode COPY est terminée, elle DOIT avoir créé au niveau de la destination un espace de noms régulier (se référer à la section 5.1 pour la définition des espaces de noms réguliers). Toutefois, si une erreur se produit pendant la copie d'une collection interne, le serveur NE DOIT copier aucune des ressources identifiées par les membres de cette collection (en clair, par exemple, le serveur DOIT ignorer le sous-arbre de cette collection), parce que cela reviendrait sinon à créer un espace de noms irrégulier. Quand une erreur est ainsi détectée, l'opération de COPY DEVRAIT essayer de se terminer de manière à ce que le résultat soit le plus proche possible de ce qu'était la ressource source à copier (par exemple, le serveur doit essayer de copier les autres sous-arbres et leurs membres de la ressource source, ceux qui ne sont pas des descendants de la collection ayant causé le problème). Par exemple, si un COPY avec une profondeur infinity est appliqué à la collection /a/, contenant les collections /a/b/ et /a/c/, et qu'une erreur intervient lors de la copie de /a/b/, alors la méthode doit quand même essayer de copier /a/c/.

De la même manière, si une erreur arrive lors de la copie d'une ressource qui n'est pas une collection et dans le cas d'un COPY de type infinity, le serveur DEVRAIT essayer de terminer le traitement en rendant un résultat qui soit le plus proche possible du résultat souhaité. Si une erreur dans l'exécution de la méthode COPY survient sur une ressource autre que celle identifiée par l'URI requête alors la réponse DOIT être le code 207 (multi-état).

Le code 424 (Echec de dépendance) NE DEVRAIT PAS être retourné dans une réponse de type 207 (multi-état) résultant de l'exécution de la méthode COPY. Les réponses peuvent être omises en toute sécurité parce que le client sera informé que la progéniture d'une ressource n'a pas pu être copiée quand il recevra l'erreur relatve aux parents. De plus, les codes 201 (Créé) et 204 (Pas de contenu) NE DEVRAIT PAS être retournés dans les réponses 207 (états multiples) produites par la méthode COPY. Elles peuvent également être omises en toute sécurité parce qu'il s'agit des codes par défaut en cas de réussite.

8.8.4 Méthode COPY et entête Overwrite

Si une des ressources copiées existe au niveau de la destination spécifiée et que l'entête Overwrite vaut "T" alors, avant d'exécuter la copie, le serveur DOIT exécuter un DELETE de la ressource de destination correspondante avec l'option "Depth: infinity". Si l'entête Overwrite est initialisée à "F" alors l'opération doit échouer.

8.8.5 Codes d'états

201 (Créé) - La ressource source a été copiée avec succès. Le résultat de cette opération est la création d'une nouvelle ressource.

204 (Pas de contenu) - La ressource source a été copiée avec succès vers une ressource de destination pré-existante.

403 (Interdit) - Les URI de la source et de la destination sont les mêmes.

409 (Conflit) - Une des ressources ne peut pas être créée au niveau de la destination tant qu'une ou plusieurs collections intermédiaires n'auront pas été créées.

412 (Echec de la précondition) - Le serveur a été incapable de maintenir l'aspect vivant des propriétés listées dans l'élément XML propertybehavior ou bien l'entête Overwrite vaut "F" et l'état de la collection de destination n'est pas nul.

423 (Verrouillé) - La ressource de destination était verrouillée.

502 (Mauvaise passerelle) - Cela peut arriver quand la destination se trouve être sur un autre serveur et que ce dernier refuse d'accepter la ressource.

507 (Mémoire insuffisante) - La ressource de destination n'a pas assez d'espace pour enregistrer l'état de la ressource après exécution de cette méthode.

8.8.6 exemple - COPY avec Overwrite

Dans cet exemple, la ressource http://www.ics.uci.edu/~fielding/index.html est copiée à la destination http://www.ics.uci.edu/users/f/fielding/index.html. Le code d'état 204 (Pas de contenu) indique que la ressource de destination qui existait été écrasée.

>>Requête

COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html

>>Réponse

HTTP/1.1 204 No Content

8.8.7 exemple - COPY sans Overwrite

L'exemple suivant montre la même opération de copie, mais en ayant mis l'entête Overwrite à "F." Une réponse de type 412 (Echec de précondition) est retournée parce que la ressource de destination n'était pas dans un état nul.

>>Requête

COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html Overwrite: F

>>Réponse

HTTP/1.1 412 Precondition Failed

8.8.8 exemple - COPY d'une collection

>>Requête

COPY /container/ HTTP/1.1
Host: www.foo.bar
Destination: http://www.foo.bar/othercontainer/
Depth: infinity
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

      <?xml version="1.0" encoding="utf-8" ?>
      <d:propertybehavior xmlns:d="DAV:">
        <d:keepalive>*</d:keepalive>
      </d:propertybehavior>

>>Réponse

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

      <?xml version="1.0" encoding="utf-8" ?>
      <d:multistatus xmlns:d="DAV:">
        <d:response>
             <d:href>http://www.foo.bar/othercontainer/R2/</d:href>
             <d:status>HTTP/1.1 412 Precondition Failed</d:status>
        </d:response>
      </d:multistatus>

L'entête Depth est inutilement précisée car infinity est la valeur par défaut de toute opération de COPY de collection. Dans cette exemple, la plupart des resssources de la collection furent copiées avec succès. Toutefois la copie de la collection R2 a échoué, probablement à cause d'un problème lié au maintient de propriétés vivantes (cela est spécifié par l'élément XML propertybehavior). Comme il y eut cette erreur sur R2, aucun des membres de R2 ne fut copié. Toutefois aucune erreur n'a été inscrite dans la réponse pour les membres en question à cause de la règle de minimisation des erreurs décrites à la section 8.8.3.

8.9 Méthode MOVE

Le déplacement d'une ressource qui ne soit pas une collection par la méthode MOVE est logiquement équivalent à l'exécution d'un COPY, suivi par un traitement de maintenance de la régularité, suivi d'une destruction de la source, les trois actions étant exécutées automatiquement. L'étape de maintenance de la régularité autorise le serveur à exécuter les actions de mises à jour consécutives au déplacement, comme par exemple la mise à jour de toutes les URI autres que l'URI requête qui identifie la ressource source, pour les faire pointer vers la nouvelle resssource destination. En conséquence, l'entête Destination DOIT être présente sur toutes les méthodes MOVE et DOIT suivre toutes les exigences de la méthode COPY, tout au moins pour la partie identique à COPY de la méthode MOVE. Toutes les ressources conformes à DAV DOIVENT supporter la méthode MOVE. Toutefois, le support de la méthode MOVE n'est pas une garantie que le serveur aura la capacité de déplacer une ressource source vers une destination particulière.

Par exemple, des programmes indépendants les uns des autres peuvent avoir, sur le même serveur, le contrôle de différents ensembles de ressources. Dès lors, il se pourrait qu'il ne soit pas possible de déplacer une ressource d'un ensemble à un autre, c'est à dire à l'intérieur d'un espace de noms qui se trouve pourtant être sur le même serveur.

Si une ressource existe au niveau de la destination spécifiée, un effet de bord de la méthode MOVE est que la ressource destination sera DETRUITE , cela dans la limite des éventuelles restrictions dues à l'entête Overwrite.

8.9.1 Méthode MOVE appliquée aux propriétés

Le comportement des propriétés lors de l'exécution d'un MOVE, y compris les effets de l'élément XML propertybehavior, DOIT être le même que celui spécifié dans la section 8.8.2.

8.9.2 Méthode MOVE appliquée à des collections

L'entête "Depth: infinity" utilisée la méthode MOVE est une instruction qui sert à déplacer la colllection identifiée par l'URI requête vers l'URI spécifiée dans l'entête Destination et précise que toutes les ressources identifiées par les URI de membres internes de la ressource source, à tous les niveaux hiérarchiques, sont à déplacer récursivement vers des emplacements de la ressource de destination qui lui seront relatifs.

La méthode MOVE appliquée à une collection DOIT agir comme si l'entête "Depth: infinity" était utilisée. Un client NE DOIT soumettre aucune autre valeur d'entête que "Depth: infinity" avec un MOVE.

Toutes les entêtes incluses dans un MOVE DOIVENT être appliquées à chaque ressource lors de son déplacement à l'exception de la ressource spécifiée dans l'entête Destination.

Le comportement de l'entête Destination est le même que celui défini pour la COPY de collections.

Quand l'exécution de la méthode MOVE est terminée, elle DOIT avoir créé un espace de noms régulier tant au niveau de la source que de la destination (se référer à la section 5.1 pour voir la définition de la notion d'espace de noms régulier). Toutefois, si une erreur survient pendant le déplacement d'une collection interne, le serveur NE DOIT déplacer aucune des resources identifiées par les membres de la collection génératrice de l'erreur (par exemple, le serveur DOIT sauter le sous-arbre ayant provoqué l'erreur et passer à un autre), parce que cela créerait un espace de nom irrégulier. Dans ce cas, après que l'erreur soit détectée, l'opération de déplacement DEVRAIT essayer de terminer l'action de manière à obtenir un résultat le plus proche possible de celui espéré initialement (par exemple, le serveur devrait continuer à essayer de déplacer les autres sous-arbres et les ressources identifiées par leurs membres qui ne sont pas les descendants d'une collection auant provoqué une erreur). Par exemple, si un MOVE de profondeur infinie est exécuté sur la collection /a/, contenant les collections /a/b/ et /a/c/, et qu'une erreur survient dans le déplacement /a/b/, le serveur doit quand même essayer de déplacer /a/c/. Similairement, après qu'une erreur soit rencontrée lors du déplacement d'une ressource autre qu'une collection et dans le cas d'un MOVE de profondeur infinie, le serveur DEVRAIT doit essayer de terminer l'opération demandée de manière à obtenir un résultat le plus proche possible de celui attendu par l'opération de déplacement originellement demandée.

Si une erreur se produit avec une ressource autre que celle identifiée par l'URI requête alors la réponse DOIT être un code 207 (états multiples).

Le code d'état 424 (Echec de dépendance) NE DEVRAIT PAS être retourné dans le cas d'une réponse 207 (états multiples) produite par une méthode MOVE. Ces erreurs peuvent être omises en toute sécurité parce que le client saura que la progéniture d'une ressource ne peut pas être déplacée quand il recevra le message d'erreur concernant le parent. De plus, les réponses 201 (Créé)/204 (Pas de contenu) NE DEVRAIENT PAS être retournées dans une réponse 207 (états multiples) à un MOVE. Ces réponses peuvent être omises en toute sécurité parce qu'il s'agit des codes par défaut des déplacements réussis.

8.9.3 Méthode MOVE et l'entête Overwrite

Si une ressource existe à l'emplacement défini comme destination et que l'entête Overwrite est "T" alors, avant d'exécuter le déplacement le serveur DOIT exécuter un DELETE de profondeur infinie de la ressource destination. Si l'entête Overwrite est "F" alors l'opération échouera.

8.9.4 Codes d'états

201 (Créé) - La ressource source a été déplacée avec succès, et une nouvelle ressource a été créée à la destination indiquée.

204 (Pas de contenu) - La ressource source a été déplacée avec succès vers une ressource destination qui existait déjà.

403 (Interdit) - Les URI de la source et de la destination sont les mêmes.

409 (Conflit) - Une ressource ne peut pas être créée à la destination tant qu'une ou plusieurs collections intermédiaires n'auront pas été créées.

412 (Echec de la précondition) - Soit le serveur a été incapable de maintenir l'aspect vivant des propriétés listées dans l'élément XML propertybehavior soit l'entête Overwrite vaut "F" et l'état de la ressource destination n'est pas nul.

423 (Verrouillé) - La source ou la destination était verrouillée.

502 (Mauvaise passerelle) - Cela peut survenir quand la destination est sur un autre serveur et que le serveur de la destination refuse de recevoir la ressource.

8.9.5 exemple - MOVE d'une ressource autre qu'une collection

Cette exemple montre le déplacement de la ressource http://www.ics.uci.edu/~fielding/index.html vers la destination http://www.ics.uci.edu/users/f/fielding/index.html. Le contenu de la ressource de destination serait écrasé si la ressource destination était non-nulle. Dans ce cas, puisqu'il n'y avait rien dans la ressource de destination, le code de réponse retourné est 201 (Créé).

>>Requête

MOVE /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html

>>Réponse

HTTP/1.1 201 Created
Location: http://www.ics.uci.edu/users/f/fielding/index.html

8.9.6 exemple - MOVE d'une collection

>>Requête

MOVE /container/ HTTP/1.1
Host: www.foo.bar
Destination: http://www.foo.bar/othercontainer/
Overwrite: F
If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>) (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>) Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <d:propertybehavior xmlns:d='DAV:'>
    
<d:keepalive>*</d:keepalive>
   </d:propertybehavior>

>>Réponse

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <d:multistatus xmlns:d='DAV:'>
     <d:response>
          <d:href>http://www.foo.bar/othercontainer/C2/</d:href>
          <d:status>HTTP/1.1 423 Locked</d:status>
     </d:response>
   </d:multistatus>

Dans cet exemple, le client a soumis un certain nombre de verrous avec sa requête. Un marqueur de verrou sera nécessaire pour chaque ressource verrouillée, source et destination, quelque soit l'endroit où elle se trouve dans le domaine d'application de la méthode. Dans ce cas, le marqueur de verrou approprié n'a pas été soumis pour la destination http://www.foo.bar/othercontainer/C2/. Cela signifie que la ressource /container/C2/ n'a pas pu être déplacée. Et comme il y a eu une erreur sur la copie de /container/C2/, alors aucun des membres de ce répertoire ne fut copié.  Toutefois, aucune erreur ne fut inscrite dans la réponse pour ces membres à cause de la règle de minimisation des erreurs définies à la section 8.8.3. L'identification de l'agent utilisateur est déjà intervenue via un mécanisme externe au domaine du protocole HTTP, dans une couche de transport sous-jacente.

8.10 Méthode LOCK

La section suivante décrit la méthode LOCK, utilisée pour poser un verrou. Les sections concernant la méthode LOCK décrivent uniquement la sémantique spécifique à la méthode LOCK et sont indépendantes du type d'accès contrôlé par le verrou.

Toute ressource qui supporte la méthode LOCK DOIT, au minimum, supporter les formats XML de requête et de réponse définis ci-après.

8.10.1 Fonctionnement

L'invocation de la méthode LOCK crée le verrou spécifié par l'élément XML lockinfo de l'URI requête. Les requêtes portant sur la méthode de verrouillage DEVRAIENT avoir un corps de requête en XML contenant l'élément XML owner, sauf si il s'agit d'une requête de rafraîchissement. La requête LOCK peut avoir dans son entête une valeur de contrôle de de limitation dans le temps (un "Timeout").

Les clients DOIVENT assumer le fait que les verrous peuvent disparaître arbitrairement à tout instant, cela indépendamment de toute valeur de contrôle de limitation dans le temps qui aurait été spécifiée dans l'entête. L'entête de contrôle de limitation dans le temps ne fait qu'indiquer au serveur quel est le comportement à suivre dans des cas de circonstances extraordinaires. Par exemple, un administrateur peut retirer un verrou à tout instant ou le système peut s'arrêter brutalement de telle manière qu'il perde l'enregistrement de l'existence du verrou. La réponse DOIT contenir dans l'élément XML prop la valeur de la propriété lockdiscovery.

Afin d'indiquer le marqueur de verrou associé au verrou nouvellement créé, une entête de réponse de type Lock-Token DOIT être incluse dans la réponse pour chaque demande de verrou de la requête LOCK ayant réussi. Remarquez que l'entête Lock-Token ne serait pas retournée en réponse à une requête de rafraîchissement de verrou parce que dans ce cas, il n'y a aucune création de nouveau verrou.

8.10.2 L'effet des verrous sur les propriétés et les collections

Un verrou porte l'état de la totalité de la ressource, incluant son corps et ses propriétés associées. En conséquence, un verrou sur une ressource DOIT aussi verrouiller les propriétés de la ressource.

Pour les collections, le verrou concerne également la possibilité d'y ajouter ou d'en détruire des membres. La nature de l'effet dépend du type de contrôle d'accès en vigueur.

8.10.3 Verrouillage de ressources dupliquées

Une ressource peut être rendue accessible par différentes URI. Toutefois les verrous s'appliquent aux ressources, pas aux URI. De ce faite, une requête LOCK sur une ressource NE DOIT réussir que si elle peut être honorée par toutes les URI au travers desquelles la ressource est accessible.

8.10.4 Valeur de Depth et verrouillage

L'entête Depth peut être utilisée avec la méthode LOCK. Seules les valeurs "0" (zéro) et "infinity" SONT autorisées. Toutes les ressources qui supportent la méthode LOCK DOIVENT supporter l'entête Depth.

Une entête Depth de valeur 0 (zéro) signifie simplement qu'il ne faut verrouiller que la ressource spécifiée par l'URI requête.

Si l'entête Depth est initialisée à la valeur infinity alors la ressource spécifiée par l'URI requête ainsi que tous ses membres internes, jusqu'au plus bas niveau de la hiérarchie, doivent être verrouillés. Un résultat réussi DOIT retourner un seul marqueur de verrou représentant toutes les ressources qui ont été verrouillées. Si un UNLOCK est exécuté avec succès sur ce marqueur, toutes les ressources associées sont déverrouillées. Si le verrouillage ne peut pas être accordé à toutes les ressources, un code 409 (Conflit) DOIT être retourné dans le corps de la réponse contenant l'élément XML multistatus décrivant quelle(s) ressource(s) a empêché le verrou d'être accordé. Mais le succès partiel n'est pas une option autorisée. Soit toute la hiérarchie est verrouillée soit aucune ressource ne l'est.

Quand aucune entête Depth n'est soumise avec la requête LOCK alors la valeur par défaut "Depth:infinity" est appliquée.

8.10.5 Interaction avec d'autres méthodes

L'interaction du LOCK avec différentes méthodes dépend du type de verrou. Toutefois, indépendamment du type de verrou, la destruction réussie d'une ressource avec la méthode DELETE DOIT entraîner la destruction de tous les verrous qui sont rattachés à cette ressource.

8.10.6 Tableau de compatibilité des verrous

La table ci-dessous décrit le comportement de la méthode quand une requête de verrouillage est appliquée à une ressource.

   état courant du verrou/  |   verrou partagé    |   Verrou
   requête de verrou        |                     |   exclusif
   =========================+=====================+==============
   aucun                    |   Vrai              |   Vrai
   -------------------------+---------------------+--------------
   Verrou partagé           |   Vrai              |   Faux
   -------------------------+---------------------+--------------
   Verrou exclusif          |   Faux              |   Faux*
   --------------------------------------------------------------

Légende : Vrai = le verrou peut être accordé. Faux = le verrou NE DOIT PAS être accordé. *=Il est interdit à un demandeur de demander deux fois de suite le même verrou.

L'état de verrouillage courant d'une ressource est indiqué dans la colonne la plus à gauche, et les différents cas de demandes de verrouillage sont listés dans la première rangée. A l'intersection d'une colonne et d'une rangée se trouve le résultat de la demande de verrouillage. Par exemple, si un verrou partagé est posé une ressource, et qu'une demande de verrou exclusif est faite, l'entrée dans la table donne la valeur "faux", indiquant que le verrou NE DOIT PAS être accordé.

8.10.7 Codes d'états

200 (OK) - La demande de verrouillage a réussie et la valeur de la propriété lockdiscovery est incluse dans le corps.

412 (Echec de la précondition) - Soit le marqueur de verrou inclus n'a pas pu être imposé à cette ressource soit le serveur n'a pas pu satisfaire la demande précisée dans l'élément XML lockinfo.

423 (Verrouillé) - La ressource est verrouillée, donc la méthode a été rejetée.

8.10.8 Exemple - Une demande de verrouillage simple

>>Requête

LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."

   <?xml version="1.0" encoding="utf-8" ?>
   <D:lockinfo xmlns:D='DAV:'>
     <D:lockscope><D:exclusive/></D:lockscope>
     <D:locktype><D:write/></D:locktype>
     <D:owner>
          <D:href>http://www.ics.uci.edu/~ejw/contact.html</d:href>
     </D:owner>
   </D:lockinfo>

>>Réponse

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:prop xmlns:D="DAV:">
     <D:lockdiscovery>
          <D:activelock>
               <D:locktype><D:write/></D:locktype>
               <D:lockscope><D:exclusive/></D:lockscope>
               <D:depth>Infinity</D:depth>
               <D:owner>
                    <D:href>http://www.ics.uci.edu/~ejw/contact.html </D:href>
               </D:owner>
               <D:timeout>Second-604800</D:timeout>
               <D:locktoken>
                    <D:href>opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
               </D:locktoken>
          </D:activelock>
     </D:lockdiscovery>
   </D:prop>

Cet exemple montre la création réussie d'un verrou d'écriture exclusif sur la ressource http://webdav.sb.aol.com/workspace/webdav/proposal.doc. La ressource http://www.ics.uci.edu/~ejw/contact.html contient les données d'identification du propriétaire du verrou. Le serveur a une politique de gestion du temps limite basée sur l'activité de cette ressource, et entraîne la destruction automatique du verrou après une semaine (604800 secondes). Remarquez que les champs nonce, response, et opaque n'ont pas été calculés dans l'entête Authorization de la requête.

8.10.9 Exemple - rafraîchissement d'un verrou d'écriture

>>Requête

LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000
If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>) Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."

>>Réponse

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:prop xmlns:D="DAV:">
     <D:lockdiscovery>
          <D:activelock>
               <D:locktype><D:write/></D:locktype>
               <D:lockscope><D:exclusive/></D:lockscope>
               <D:depth>Infinity</D:depth>
               <D:owner>
                    <D:href>http://www.ics.uci.edu/~ejw/contact.html </D:href>
               </D:owner>
               <D:timeout>Second-604800</D:timeout>
               <D:locktoken>
                    <D:href>opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
               </D:locktoken>
          </D:activelock>
     </D:lockdiscovery>
   </D:prop>

Cette demande rafraîchirait le verrou en réinitialisant tous les compteurs de limitation de temps. Remarquez que le client a demandé un temps infini mais que le serveur a choisi d'ignorer cette demande. Dans cet exemple, les champs nonce, response, et opaque n'ont pas été calculés dans l'entête Authorization de la requête.

8.10.10 Exemple - requête de verrou sur plusieurs ressources

>>Requête

LOCK /webdav/ HTTP/1.1
Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000
Depth: infinity
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."

   <?xml version="1.0" encoding="utf-8" ?>
   <D:lockinfo xmlns:D="DAV:">
     <D:locktype><D:write/></D:locktype>
     <D:lockscope><D:exclusive/></D:lockscope>
     <D:owner>
          <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
     </D:owner>
   </D:lockinfo>

>>Réponse

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:">
     <D:response>
          <D:href>http://webdav.sb.aol.com/webdav/secret</D:href>
          <D:status>HTTP/1.1 403 Forbidden</D:status>
     </D:response>
     <D:response>
          <D:href>http://webdav.sb.aol.com/webdav/</D:href>
          <D:propstat>
               <D:prop><D:lockdiscovery/></D:prop>
               <D:status>HTTP/1.1 424 Failed Dependency</D:status>
          </D:propstat>
     </D:response>
   </D:multistatus>

Cet exemple montre une demande de pose d'un verrou d'écriture exclusif sur une collection et tout ses enfants. Dans cette requête, le client a spécifié qu'il souhaite obtenir un verrou de durée infinie, si un tel verrou est disponible, et, dans le cas contraire, souhaite obtenir un temps limité à 4.1 millliards de secondes, si cela est possible. Le corps de l'entité requête contient l'information d'identification du demandeur faisant la demande de verouillage, ici, il s'agit de l'URL d'une page web.

La réponse retournée concernant la ressource http://webdav.sb.aol.com/webdav/secret est 403 (Interdit). Et comme cette ressource ne put être verrouillée, aucune autre ne le fut. Remarquez aussi que la propriété lockdiscovery de l'URI requête a été incluse dans la réponse comme cela est exigé. Dans cet exemple, la propriété lockdiscovery est vide, ce qui signifie qu'il n'y a actuellement aucun verrou de posé sur cette ressource.

Dans cet exemple, les champs nonce, response, et opaque n'ont pas été calculés dans l'entête Authorization de la requête.

8.11 Méthode UNLOCK

La méthode UNLOCK supprime de l'URI requête le verrou identifié par le marqueur de verrou spécifié dans le champ Lock-Token de l'entête de la requête ainsi que de toutes les ressources incluses dans le verrou. Si toutes les ressources qui ont été verrouillées par le marqueur de verrou ne peuvent être déverrouillées alors la requête UNLOCK DOIT échouer.

Toute ressource conforme à DAV et supportant la méthode LOCK DOIT supporter la méthode UNLOCK.

8.11.1 Exemple - UNLOCK

>>Requête

UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: webdav.sb.aol.com
Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7> Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."

>>Réponse

HTTP/1.1 204 No Content

Dans cet exemple, le verrou identifié par le marqueur de verrou "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" est retiré avec succès de la ressource http://webdav.sb.aol.com/workspace/webdav/info.doc. Si ce verrou avait inclu plus d'une ressource, le verrou aurait été supprimé sur chacune d'elles. Le code d'état 204 (Pas de contenu) est utilisé au lieu du code 200 (OK) parce que l'entité réponse n'a pas de corps.

Dans cet exemple, les champs nonce, response, et opaque n'ont pas été calculés dans l'entête Authorization de la requête.

9 Les entêtes HTTP pour la rédaction distribuée

9.1 Entête DAV

DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]

Cet entête indique que la ressource supporte le schéma et le protocole DAV tels que spécifiés. Toute ressource conforme à DAV DOIT retourner l'entêtes DAV avec toute réponse à la méthode OPTIONS.

La valeur est une liste de toutes les classes conformes que la ressource supporte. Remarquez que ci-dessus, une virgule a déjà été rajoutée au 2. C'est parce qu'une ressource ne peut pas avoir une conformité de niveau 2 sans être également conforme de niveau 1. Référez-vous à la section 15 pour plus de détails. En général, toutefois, le support d'une classe de conformité ne présage pas du support d'aucune autre.

9.2 Entête Depth

Depth = "Depth" ":" ("0" | "1" | "infinity")

L'entête Depth est utilisée avec les méthodes qui agissent sur des ressources qui ont potentiellement des membres internes afin de leur indiquer si la méthode doit être appliquée seulement à la ressource ("Depth: 0"), à la ressource et ses enfants immédiats ("Depth: 1"), ou à la ressource et toute sa progéniture ("Depth: infinity").

L'entête Depth est uniquement supportée si une définition de la méthode est explicitement fournie pour le support.

Les règles suivantes représentent le comportement par défaut de toute méthode supportant l'entête Depth. Une méthode peut surcharger les comportement par défaut en les redéfinissant dans sa définition.

Les méthodes qui supportent l'entête Depth peuvent décider de pas supporter toutes les valeurs possibles et définir, au cas par cas, le comportement de la méthode lorsque l'entête Depth est absente. Par exmeple, la méthode MOVE ne supporte que la valeur "Depth: infinity" et si l'entête Depth est absente elle agit comme si la valeur "Depth: infinity" avait été spécifiée.

Les clients NE DOIVENT PAS considérer que les méthodes s'exécutant sur les membres de leurs arborescences le font selon un ordre ou une exécution atomique particulière à moins que la méthode n'en fournisse explicitement la garantie.

Pour son exécution, une méthode ayant une entête Depth exécutera le mieux possible la tâche qui lui est assignée puis retournera une réponse spécifiant ce qui fut achevé et ce qui fut impossible à réaliser.

Ainsi, par exemple, une tentative de copie d'arborescence avec la méthode COPY peut réussir sur certains membres et échouer sur d'autres.

Toute entête de méthode dont le comportement dépend de la valeur de l'entête Depth DOIT être appliquée à toutes les ressources se trouvant dans le champ d'application de la méthode excepté aux endroits où des comportements différents ont été clairement spécifiés. Par exemple, une entête If-Match verra sa valeur appliquée à chaque ressource se trouvant dans le champ de la méthode et entraînera son échec sur les ressources ne satisfaisant pas à cette précondition.

Si une ressource, source ou destination, se trouvant à l'intérieur du champ d'application de la méthode ayant une entête Depth est verrouillée de telle manière que la méthode ne peut réussir, alors le marqueur de verrou de cette ressource DOIT être soumis en même temps que la requête dans l'entête If de la requête .

L'entête Depth ne fait que spécifier le comportement de la méthode au regard de ses enfants internes. Si une ressource n'a pas d'enfant interne alors l'entête Depth DOIT être ignorée.

Remarquez bien que c'est toujours une erreur que de soumettre une valeur d'entête Depth qui ne soit pas autorisée par la définition de la méthode. Aussi, soumettre un "Depth: 1" avec la méthode COPY, même si la ressource n'a aucun membre interne, entraînera le retour d'un code 400 (mauvaise requête). La méthode doit échouer non pas parce que la ressource n'a pas de membre interne mais à cause de la valeur interdite de l'entête Depth.

9.3 Entête Destination

Destination = "Destination" ":" absoluteURI

L'entête Destination spécifie l'URI des ressources destination des méthodes de type COPY et MOVE, qui ont besoin d'avoir deux URI en paramètres. Remarquez que la règle de production de absoluteURI est définie dans [RFC2396].

9.4 Entête If

If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
No-tag-list = List
Tagged-list = Resource 1*List
Resource = Coded-URL
List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")" State-token = Coded-URL
Coded-URL = "<" absoluteURI ">"

L'entête If a un objectif fonctionnel similaire à l'entête If-Match définie à la section 14.25 de [RFC2068]. Cependant, l'entête If est sensée être utilisée avec toute URI représentant une information d'état, référencée par un marqueur d'état, concernant tant une ressource qu'un ETags. Un cas typique de marqueur d'état est un marqueur de verrou, et les marqueurs de verrou sont les seuls marqueurs d'états définis dans cette spécification.

Toute ressource conforme à DAV DOIT supporter l'entête If.

Le but de l'entête If est de décrire une série de listes d'états. Si l'état de la ressource à laquelle l'entête est appliquée ne correspond à aucun des états spécifiés alors la requête DOIT échouer avec un code 412 (Echec de la précondition). Si l'un des états décrits correspond à l'état de la ressource alors la requête peut réussir.

Remarquez que la règle de production de absoluteURI est définie dans [RFC2396].

9.4.1 Règle de production de No-tag-list

La règle de production de No-tag-list permet de décrire une série de marqueurs d'état et d'ETags. Si plusieurs No-tag-list sont utilisés alors il suffit qu'un seul d'entre eux corresponde à l'état de la ressource pour que la requête puisse continuer.

Si une méthode, de par la présence d'une entête Depth ou Destination, s'applique à plusieurs ressources alors la règle de produciton No-tag-list DOIT être appliqué à chacune des ressources sur laquelle est appliquée la méthode.

9.4.1.1 Exemple - Entête IF avec un No-tag-list

If: (<locktoken:a-write-lock-token> ["I am an ETag"]) (["I am another ETag"])

L'entête précédente signifie que toute ressource présente dans le champ d'application de la méthode DOIT, soit être verrouillée avec le marqueur de verrou spécifié et être dans l'état défini par le premier Etag "I am an ETag" soit être dans l'état identifié par le second Etag "I am another ETag". Pour être tout à fait clair, on peut imaginer l'entête If précédente comme étant écrite sous la forme (or (and <locktoken:a-write-lock-token> ["I am an ETag"]) (and ["I am another ETag"])).

9.4.2 Règle de production de Tagged-list

La règle de production tagged-list s'applique à la production d'une liste ne s'appliquant qu'à la ressource qui la précède. Le champ d'application de la règle commence immédiatement après la spécification de la ressource et se termine avec la spécification de la ressource suivante, si il y en a une.

Quand l'entête If est appliquée à une ressource particulière, le serveur DOIT chercher l'existence de Tagged-list pour savoir si une des ressources listées correspond à la (aux) ressource(s) opérande(s) pour la méthode en cours. Si aucune des règles de production de ressources ne correspond à la ressource courante alors l'entête DOIT être ignorée. Si l'une des règles de production de ressource correspond effectivement à la ressource considérée alors la liste de production de ressources suivante DOIT être appliquée à la ressource de la manière spécifiée dans la section précédente.

La même URI NE DOIT PAS apparaître plus d'une fois dans une règle de production d'une ressource dans une entête If.

9.4.2.1 Exemple - entête If avec Tagged-List

COPY /resource1 HTTP/1.1
Host: www.foo.bar
Destination: http://www.foo.bar/resource2
If: <http://www.foo.bar/resource1> (<locktoken:a-write-lock-token> [W/"A weak ETag"]) (["strong ETag"])
<http://www.bar.bar/random>(["another strong ETag"])

Dans cet exemple, la ressource http://www.foo.bar/resource1 est copiée à la ressource de destination http://www.foo.bar/resource2. Quand la méthode est appliquée pour la première fois à http://www.foo.bar/resource1, resource1 DOIT être dans l'état spécifié par "(<locktoken:a-write-lock-token> [W/"A weak ETag"]) (["strong ETag"])", c'est à dire, qu'elle DOIT être, soit verrouillée avec un marqueur de verroude type "locktoken:a-write-lock-token" et avoir une balise d'entité faible W/"A weak ETag" soit avoir une balise d'entité forte "strong ETag".

Cela est la seule condition de succès puisque la ressource http://www.bar.bar/random ne se voit jamais appliquer la méthode (la seule autre ressource listée dans l'entête If) et http://www.foo.bar/resource2 n'est pas listée dans l'entête If.

9.4.3 règle de production de not

Chaque marqueur d'état ou ETag est soit courant, et par conséquent décrit l'état de la ressource, soit n'est pas courant, et ne décrit pas l'état de la ressource. L'opération booléenne qui consiste à faire correspondre un marqueur d'état ou ETag avec l'état courant d'une ressource se résume à une valeur true ou false. La règle de production not est utilisée pour inverser cette valeur. La portée de la règle de production not est le state-token ou entity-tag qui le suit immédiatement.

If: (Not <locktoken:write1> <locktoken:write2>)

Quand cette entête If est soumise avec une requête, elle implique que toutes les ressources opérandes NE DOIVENT PAS être verrouillées avec locktoken:write1 mais DOIVENT être verrouillées avec locktoken:write2.

9.4.4 Fonction Matching

Quand l'entête If est traitée, la définition de la correspondance d'un marqueur d'état ou d'une balise d'entité se fait come suit :

Correspondance d'une balise d'entité (Matching entity tag) : quand la balise d'entité correspond à une balise d'entité associée à la ressource.

Correspondance d'un marqueur d'état (Matching state token) : quand il y a une correspondance parfaite entre le marqueur d'état dans l'entête If et l'un des marqueurs d'état de la ressource.

9.4.5 Entête If et les proxies non conformes à DAV

Les proxies qui ne sont pas conformes à DAV ne sauront pas traiter l'entête If et HTTP impose que les entêtes incomprises soient ignorées. Donc, quand on communique avec des proxies par le protocole HTTP/1.1, l'entête de requête "Cache-Control: no-cache" DOIT être utilisée afin d'empêcher que le proxy essaie, mal, de satisfaire la requête en utilisant sa mémoire cache. Avec les proxies HTTP/1.0 l'entête de requête "Pragma: no-cache" DOIT être utilisée pour les mêmes raisons.

9.5 Entête Lock-Token

Lock-Token = "Lock-Token" ":" Coded-URL

L'entête Lock-Token est utilisée dans les requêtes de la méthode UNLOCK pour identifier le marqueur de verrou à retirer. Le marqueur de verrou spécifié dans l'entête de requête Lock-Token DOIT identifier un verrou s'appliquant à une ressource reconnue de l'URI requête (c'est à dire s'appliquer à un membre de cette URI requête).

L'entête Lock-Token est utilisée dans les réponses aux requêtes de la méthode LOCK pour indiquer le marqueur de verrou créé quand la requête a réussie et qu'un nouveau verrou a été créé.

9.6 Entête Overwrite

Overwrite = "Overwrite" ":" ("T" | "F")

L'entête Overwrite précise si le serveur doit écraser l'état d'une ressource destination non-nulle en cas de COPY ou MOVE. La valeur "F" signifie que le serveur NE DOIT PAS exécuter le COPY ou le MOVE si l'état de la ressource de destination est non-nul. si l'entête overwrite n'est pas incluse dans une requête COPY ou MOVE alors la ressource DOIT utiliser la vaeur par défaut "T". Tandis que l'entête Overwrite semble dupliquer la fonctionnalité de l'entête If-Match: * de HTTP/1.1, If-Match s'applique uniquement à l'URI requête, et pas à la Destination d'un COPY ou d'un MOVE.

Si un COPY ou un MOVE ne peut pas s'exécuter à cause de la valeur de son entête Overwrite, la méthode DOIT alors échouer et retourner le code d'état 412 (Echec de la précondition).

Toute ressource conforme à DAV DOIT supporter l'entête Overwrite.

9.7 Entête de réponse Status-URI

L'entête de réponse Status-URI peut être utilisée avec le code d'état 102 (traitement) pour transmettre une information au client comme par exemple sur l'état d'une méthode.

Status-URI = "Status-URI" ":" *(Status-Code Coded-URL) ; Status-Code est défini en 6.1.1 de [RFC2068]

Les URI listées dans l'entête sont des ressources de type source qui ont été modifiées par la méthode en suspens. Le code d'état indique si la méthode a pu être appliquée à la ressource identifiée. Ainsi, par exemple, si une méthode MOVE appliquée à une collection est en suspens et qu'une réponse 102 (traitement) est retournée dans l'entête de réponse Status-URI, les URI incluses permettront de connaître les ressources que la méthode a tenté de déplacer et quel en fut le résultat.

9.8 Entête de requête Timeout

TimeOut = "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other) DAVTimeOutVal = 1*digit

   Other = "Extend" field-value   ; Voir la section 4.2 of [RFC2068]

Les clients peuvent inclure les entêtes Timeout dans leurs requêtes LOCK. Toutefois, le serveur n'est pas obligé d'honorer voir même seulement de considérer ces entêtes. Les entêtes Timeout sont réservées aux requêtes portant sur la méthode LOCK : les clients NE DOIVENT PAS soumettre d'entête Timeout avec toute méthode autre que la méthode LOCK.

L'entête Timeout DOIT contenir au moins un TimeType et peut en contenir plusieurs. L'objectif d'une liste de TimeType est de pouvoir indiquer au client plusieurs valeurs et types de valeurs qui lui soient acceptables. Le client liste les entrées TimeType par ordre de préférence.

Les valeurs de la réponse à un Timeout DOIVENT utiliser l'une des valeurs Second, Infinite, ou un TimeType que le client a déclaré comme lui étant familier. Le serveur est en droit de supposer que le client est familier avec n'importe lequel des TimeType qui lui a été soumis dans l'entête Timeout.

Le TimeType "Second" spécifie le nombre de secondes qui s'écouleront entre le moment ou le verrou sera accordé par le serveur et la destruction automatique de ce verrou. La valeur de limite de temps pour le TimeType "Second" NE DOIT PAS être plus grand que 232-1.

Le compteur de limite de temps DEVRAIT être réinitialisé à chaque fois que le propriétaire d'un verrou envoie une méthode à n'importe lequel des membres du verrou, y compris des méthodes non-supportées, ou des méthodes qui ont échouées. Toutefois, le verrou DOIT être rafraîchi si la méthode de rafraîchissement de LOCK est reçue avec succès.

Si la limite de temps est atteinte, alors le verrou peut être perdu. Plus précisément, si le serveur souhaite récupérer les verrous en dépassement de temps, il DOIT agir comme si il exécutait une méthode UNLOCK sur la resource utilisant le marqueur du verrou en dépassement de temps. Cela pourrait être fait au titre des privilèges que lui confère son autorité en écrasement. Des traces de cette activité devraient alors être mises à jour et indiquer l'emplacement des verrous, envoyer des notifications etc..., exactement comme cela se fait pour les requêtes de la méthode UNLOCK.

Les serveurs sont avertis qu'ils doivent prêter une attention toute particulière aux valeurs qui leurs sont soumises par les clients, puisqu'elles seront autant d'indications quant au type d'activité que le client a l'intention d'exécuter. Par exemple, une applet s'exécutant dans un navigateur peut avoir besoin de verrouiller une ressource ; mais à cause de l'instabilité de l'environnement dans lequel elle s'exécute, elle peut très bien être arrêtée sans qu'aucun message d'avertissement soit émis. En conséquence, il est fortement probable que l'applet aura besoin d'avoir un temps limite d'exécution de petite durée de manière à ce que, si elle venait à mourir, le verrou pourrait être rapidement récupéré. Toutefois, un système de gestion de documents a de fortes chances d'avoir besoin de demander des durées de temps limite extrêmement longues parce que son utilisateur peut plannifier de continuer son travail rédactionnel hors connexion.

Un client NE DOIT PAS se contenter de considérer qu'un verrou est perdu parce que le temps limite prévu a été dépassé.

10 Extension des codes d'états de HTTP/1.1

Les codes d'états suivants ont été ajoutés à ceux définis dans HTTP/1.1 [RFC2068].

10.1 Code d'état 102 : traitement

Le code d'état 102 (Traitement) est une réponse intermédiaire utilisée pour informer le client que le serveur a accepté la totalité de la requête, mais n'a pas fini de l'exécuter. Ce code d'état DEVRAIT être seulement envoyé quand le serveur a de sérieuses raisons de juger que la requête prendra un temps significatif avant d'être complètement terminée. Comme consigne générale, si le serveur détermine qu'une méthode prendra plus de 20 secondes (une valeur raisonnable, quoique arbitraire) pour exécuter un traitement, alors il DEVRAIT retourner une réponse 102 (Traitement). Le serveur DEVRA envoyer une réponse finale après l'accomplissement total de la requête.

Le traitement des méthodes peut potentiellement prendre un certain temps, particulièrement celles qui supportent l'entête Depth. dans ces cas là, le client peut interrompre sa connection avec le serveur alors qu'il est en attente d'une réponse. Pour se pémunir de cela, le serveur peut retourner un code d'état 102 (Traitement) pour informer le client qu'il est toujours en train de d'exécuter la méthode.

10.2 Code d'état 207 : états multiple

Le code d'état 207 (états multiple) fournit les états de plusieurs opérations indépendantes (référez vous à la section 11 pour plus d'informations).

10.3 Code d'état 422 : entité impossible à traiter

Le code d'état 422 (entité impossible à traiter) signifie que le serveur comprend le type de contenu de l'entité requête (jusque là un code 415 'type de média non supporté' est inapproprié), et la syntaxe de l'entité requête est correcte (donc un code d'état 400 'mauvaise requête' est également inapproprié) mais ce serveur a été incapable d'exécuter les instructions que le corps de la requête contient. Par exemple, ces conditions peuvent être réunies quand un corps de requête contient une instance XML bien formée (c'est à dire syntaxiquement correct) mais contenant des instructions XML erronées sémantiquement.

10.4 Code d'état 423 : verrouillé

Le code d'état 423 (verrouillé) signifie que la ressource source ou la destination impliquée dans une méthode est verrouillée.

10.5 Code d'état 424 : échec de dépendance

Le code d'état 424 (échec de dépendance) signifie que la méthode n'a pu s'appliquer correctement à la ressource parce que l'action demandée par la requête dépendait d'une autre qui échoua. Par exemple, si une commande d'une méthode PROPPATCH échoue alors, au minimum, le reste des commandes échouera également et cela produira un code 424 (échec de dépendance).

10.6 Code d'état 507 : mémoire insuffisante

Le code d'état 507 (mémoire insuffisante) signifie que la méthode n'a pu être exécutée correctement sur la ressource parce que le serveur est incapable de mémoriser la représentation nécessaire à l'accomplissement de la requête. Cet état est considéré comme étant momentané. Si la requête qui reçu ce code d'état était le résultat d'une action utilisateur, la requête NE DEVRAIT PAS être répétée tant que cela n'est pas demandé par une action spécifique de l'utilisateur.

11 Réponse d'états multiples

Le corps de réponse par défaut 207 (états multiples) est une entité HTTP de type text/xml ou application/xml qui contient un seul élément XML appelé multistatus, qui contient un ensemble d'éléments XML appelés response qui contiennent des suites de codes d'états 200, 300, 400, et 500 générés pendant l'invocation de la méthode. Les séries de code d'état 100 NE DEVRAIENT PAS être enrégistrées dans l'élément XML response.

12 Définitions des éléments XML

Dans la section ci-dessous, la ligne finale de chaque section fournit la déclaration du type de l'élément en utilisant le format définit dans [REC-XML]. Le champ "Valeur", quand il est présent, spécifie des restrictions additionnelles par rapport au modèle de contenu de l'élément XMl en utilisant la notation BNF (en général, il s'agit de restreindre un peu plus les valeurs possibles d'un élément XML de type PCDATA).

12.1 Elément XML activelock

Nom : activelock
Espace de noms : DAV:
Objet : Décrit un verrou posé sur une ressource.
Modèle de contenu : <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?, locktoken?) >

12.1.1 Elément XML depth

Nom : depth
Espace de noms : DAV:
Objet : La valeur de l'entête Depth.
Valeur : "0" | "1" | "infinity"
Modèle de contenu : <!ELEMENT depth (#PCDATA) >

12.1.2 Elément XML locktoken

Nom : locktoken
Espace de noms : DAV:
Objet : le marqueur de verrou associé à un verrou.
Description : Le href contient une ou plusieurs URI de marqueurs de verrous opaques qui se réfèrent toutes au même verrou (c'est à dire, la règle de production de l'URI OpaqueLockToken fournie dans la section 6.4).
Modèle de contenu : <!ELEMENT locktoken (href+) >

12.1.3 Elément XML timeout

Nom : timeout
Espace de noms : DAV:
Objet : La limite de temps associée à un verrou.
Valeur : TimeType ; Définie à la section 9.8
Modèle de contenu : <!ELEMENT timeout (#PCDATA) >

12.2 Elément XML collection

Nom : collection
Espace de noms : DAV:
Objet : Identifie la ressource associée comme étant une collection. La propriété resourcetype d'une ressource collection DOIT avoir cette valeur.
Modèle de contenu : <!ELEMENT collection EMPTY >

12.3 Elément XML href

Nom : href
Espace de noms : DAV:
Objet : Identifie le contenu de l'élément comme étant une URI.
Valeur :      URI ; Voir la section 3.2.1 of [RFC2068]
Modèle de contenu : <!ELEMENT href (#PCDATA)>

12.4 Elément XML link

Nom : link
Espace de noms : DAV:
Objet : Identifie la propriété comme étant un lien et contient la source et la destination de ce lien.
Description : L'élément XML link est utilisé pour fournir les identifiants des ressources sources et destinations d'un ou plusieurs liens lien. Le nom de la propriété qui contient l'élément XML link fournit le type du lien. Link est un élément multivalué, aussi plusieurs liens peuvent être définis ensemble pour indiquer qu'ils ont tous le même type. Les valeurs écrites dans les éléments XML href qui sont dans le contenu des éléments src et dst de l'élément XML link NE DOIVENT PAS être rejetés si ils pointent vers des ressources qui n'existent pas.
Modèle de contenu : <!ELEMENT link (src+, dst+) >

12.4.1 Elément XML dst

Nom : dst
Espace de noms : DAV:
Objet : Indique la destination d'un lien
Valeur :      URI
Modèle de contenu : <!ELEMENT dst (#PCDATA) >

12.4.2 Elément XML src

Nom : src
Espace de noms : DAV:
Objet : Indique la source d'un lien.
Valeur : URI
Modèle de contenu : <!ELEMENT src (#PCDATA) >

12.5 Elément XML lockentry

Nom : lockentry
Espace de noms : DAV:
Objet : Définit les types des verrous qui peuvent être utilisés avec la ressource.
Modèle de contenu : <!ELEMENT lockentry (lockscope, locktype) >

12.6 Elément XML lockinfo

Nom : lockinfo
Espace de noms : DAV:
Objet : L'élément XML lockinfo est utilisé avec la méthode LOCK pour spécifier le type de verrou que le client souhaite créer.
Modèle de contenu : <!ELEMENT lockinfo (lockscope, locktype, owner?) >

12.7 Elément XML lockscope

Nom : lockscope
Espace de noms : DAV:
Objet : Spécifie si un verrou est de type exclusif ou partagé.
Modèle de contenu : <!ELEMENT lockscope (exclusive | shared) >

12.7.1 Elément XML exclusive

Nom : exclusive
Espace de noms : DAV:
Objet : Spécifie un verrou exclusif
Modèle de contenu : <!ELEMENT exclusive EMPTY >

12.7.2 Elément XML shared

Nom : shared
Espace de noms : DAV:
Objet : Spécifie un verrou partagé
Modèle de contenu : <!ELEMENT shared EMPTY >

12.8 Elément XML locktype

Nom : locktype
Espace de noms : DAV:
Objet : Spécifie le type d'accès d'un verrou. Pour l'instant, cette spécification ne définit qu'un seul type de verrou, le verrou d'écriture.
Modèle de contenu : <!ELEMENT locktype (write) >

12.8.1 Elément XML write

Nom : write
Espace de noms : DAV:
Objet : Spécifie un verrou d'écriture.
Modèle de contenu : <!ELEMENT write EMPTY >

12.9 Elément XML multistatus

Nom : multistatus
Espace de noms : DAV:
Objet : Regroupe les messages d'états de plusieurs réponses.
Description : L'élément responsedescription au plus haut niveau est utilisé pour fournir un message général décrivant la nature de la réponse. Quand cette valeur est disponible, une application peut l'utiliser au lieu de présenter les descriptions individuelles de chaque réponse.
Modèle de contenu : <!ELEMENT multistatus (response+, responsedescription?) >

12.9.1 Elément XML response

Nom : response
Espace de noms : DAV:
Objet :Contient une seule réponse décrivant le résultat de l'application d'une méthode sur une ressource et/ou ses propriétés.
Description : Un href particulier NE DOIT PAS apparaître plus d'une fois en tant qu'enfant d'un élément XML response de l'élément XML multistatus. Cette condition est imposée dans un soucis de conserver une croissance linéaire du temps de traitement des réponses. Cela évite particulièrement d'avoir à rechercher tous les href dans le but de regrouper ensemble les réponses. Il n'y a cependant aucune obligation quant un quelconque ordonnancement basé sur les valeurs des href.
Modèle de contenu : <!ELEMENT response (href, ((href*, status)|(propstat+)), responsedescription?) >

12.9.1.1 Elément XML propstat

Nom : propstat
Espace de noms : DAV:
Objet : regroupement des éléments prop et status, propstat est associé à un élément href particulier.
Description : L'élément XML propstat DOIT contenir un élément XML prop et un élément XML status. Le contenu de l'élément XML prop DOIT uniquement lister les noms des propriétés auxquelles s'appliquent les résultats qui se trouvent dans l'élément status.
Modèle de contenu : <!ELEMENT propstat (prop, status, responsedescription?) >

12.9.1.2 Elément XML status

Nom : status
Espace de noms : DAV:
Objet : Contient un seul status-line HTTP
Valeur : status-line   ; défini dans [RFC2068]
Modèle de contenu : <!ELEMENT status (#PCDATA) >

12.9.2 Elément XML responsedescription

Nom : responsedescription
Espace de noms : DAV:
Objet : Contint un message qui peut être affiché à l'utilisateur expliquant la nature de la réponse.
Description : Cet élément XML fournit une information adaptée à une représentation à l'utilisateur.
Modèle de contenu : <!ELEMENT responsedescription (#PCDATA) >

12.10 Elément XML owner

Nom : owner
Espace de noms : DAV:
Objet : Fournit une information sur le demandeur qui retire un verrou.
Description : L'élément XML owner fournit assez d'information pour qu'il soit possible, soit de contacter directement un demandeur (comme un numéro de téléphone par exemple ou l'URI d'une adresse email), soit de trouver le demandeur (comme l'URL d'une page d'accueil) propriétaire du verrou.
Modèle de contenu : <!ELEMENT owner ANY>

12.11 Elément XML prop

Nom : prop
Espace de noms : DAV:
Objet : Contient les propriétés relatives à une ressource.
Description : L'élément XML prop est un élément structurel générique pour les propriétés définies sur les ressources. Tous les éléments compris à l'intérieur d'un élément XML prop NE DOIVENT définir QUE des propriétés relatives à des ressources.  Aucun autre élément ne peut être utilisé à l'intérieur d'un élément prop.
Modèle de contenu : <!ELEMENT prop ANY>

12.12 Elément XML propertybehavior

Nom : propertybehavior
Espace de noms : DAV:
Objet : Spécifie comment des propriétés sont gérées pendant les opérations COPY et MOVE.
Description : L'élément XML propertybehavior spécifie comment sont doivent être gérées certaines propriétés pendant un COPY ou un MOVE. Si cet élement XML n'est pas inclus dans le corps de la requête alors le serveur est sensé agir tel que défini dans les comportements par défaut des méthodes correspondantes. Toutes les ressources conformes à WebDav DOIVENT supporter l'élément XML propertybehavior.
Modèle de contenu : <!ELEMENT propertybehavior (omit | keepalive) >

12.12.1 Elément XML keepalive

Nom : keepalive
Espace de noms : DAV:
Objet : Spécifie la manière dont des propriétés vivantes doivent être copiées ou déplacées.
Description : Si une liste d'URI est incluse comme valeur de l'élément keepalive, alors les propriétés nommées DOIVENT être vivantes après leur copie (méthode COPY) ou leur déplacement (méthode MOVE) dans la ressource de destination. Si le contenu de l'élément XML keepalive est "*", cela signifie que toutes les propriétés vivantes de la ressource source DOIVENT être vivante dans la destination. Si les conditions spécifiées par l'élément keepalive ne peuvent pas être satisfaites alors la méthode DOIT échouer et retourner le code 412 (échec de précondition). Toutes les ressources conformes à DAV DOIVENT supporter l'élément XML keepalive dans le cadre des méthodes COPY et MOVE.
Valeur : "*" ; seule valeur autorisée comme caractère de données de type #PCDATA
Modèle de contenu : <!ELEMENT keepalive (#PCDATA | href+) >

12.12.2 Elément XML omit

Nom : omit
Espace de noms : DAV:
Objet : L'élément XML omit indique au serveur qu'il doit faire tout son possible pour copier les propriétés et qu'un échec de copie d'une propriété NE DOIT PAS provoquer l'échec de la méthode.
Description : Le comportement par défaut des méthodes COPY et MOVE est de copier/déplacer toutes les propriétés ou d'échouer. Dans certains cas, comme par exemple la copie d'une ressource en utilisant un protocole comme FTP, il peut arriver qu'il ne soit pas possible de copier/déplacer les propriétés associées à la ressource copiée/déplacée. Aussi, toutes les tentatives de copie/déplacement avec FTP échoueraient toujours parce que les propriétés ne pourraient pas être transportées, même en tant que propriétés mortes. Toute les ressources conformes à DAV  DOIVENT supporter l'élément XML omit avec les méthodes COPY/MOVE.
Modèle de contenu : <!ELEMENT omit EMPTY >

12.13 Elément XML propertyupdate

Nom : propertyupdate
Espace de noms : DAV:
Objet : Contient une requête pour modifier les propriétés d'une ressource.
Description : Cet élément XML est un élément structurel pour encadrer les informations nécessaires à la modification des propriétés d'une ressource. Cet élément XML est multivalué.
Modèle de contenu : <!ELEMENT propertyupdate (remove | set)+ >

12.13.1 Elément XML remove

Nom : remove
Espace de noms : DAV:
Objet : Liste les propriéts DAV à supprimer d'une ressource.
Description : L'élément XML remove signale que les propriétés spécifiées dans l'élément prop doivent être supprimées. On pourra noter que demander le retrait d'une propriété qui n'existe pas n'est pas une erreur.  A l'intérieur de l'élément remove, tous les éléments XML sous l'élément prop DOIVENT être vides, puisque seuls les noms des propriétés à retirer sont requis.
Modèle de contenu : <!ELEMENT remove (prop) >

12.13.2 Elément XML set

Nom : set
Espace de noms : DAV:
Objet : Liste les valeurs des propriétés DAV qui doivent être initialisées sur une ressource.
Description : L'élément XML set DOIT contenir uniquement l'élément XML prop. Les éléments contenus dans cet élément prop DOIVENT spécifier le nom et la valeur des propriétés qui doivent être initialisées sur la ressource identifiée par l'URI requête. Si une propriété existe déjà alors sa valeur est remplacée. L'information sur le langage utilisé dans la valeur de la propriété (dans l'attribut "xml:lang" quand il est présent) DOIT être enrégistrée de manière persistente avec la propriété, et DOIT être subséquemment accessible par la méthode PROPFIND.
Modèle de contenu : <!ELEMENT set (prop) >

12.14 Elément XML propfind

Nom : propfind
Espace de noms : DAV:
Objet : Spécifie les propriétés que la méthode PROPFIND doit retourner. Il y a deux éléments spécifiques à utiliser avec propfind, il s'agit de allprop et propname.  Si l'élément prop est utilisé à l'intérieur de propfind il DOIT uniquement contenir les noms des propriétés, pas leurs valeurs.
Modèle de contenu : <!ELEMENT propfind (allprop | propname | prop) >

12.14.1 Elément XML allprop

Nom : allprop
Espace de noms : DAV:
Objet : L'élément XML allprop spécifie que tous les noms et valeurs de propriétés sur la ressource doivent être retournés.
Modèle de contenu : <!ELEMENT allprop EMPTY >

12.14.2 Elément XML propname

Nom : propname
Espace de noms : DAV:
Objet : L'élément XML propname spécifie que seule une liste de noms et valeurs de propriétés de la ressource doit être retournée.
Modèle de contenu : <!ELEMENT propname EMPTY >

13 Propriétés DAV

Pour les propriétés DAV, le nom de la propriété est aussi le même que le nom de l'élément XML qui contient sa valeur. Dans la section ci-dessous, la ligne finale de chaque section fournit la déclaration du type de l'élément en utilisant le format définit dans [REC-XML]. Le champ "Valeur", là où il est présent, précise les évenuelles restrictions qu'il peut y avoir sur le contenu autorisé de l'élément XML en utilisant la notation BNF (c'est à dire, pour restreindre les valeurs du contenu des éléments dont le modèle de contenu est PCDATA).

13.1 Propriété creationdate

Nom : creationdate
Espace de noms : DAV:
Objet : Enregistre l'heure et la date à laquelle la ressource a été créée.
Valeur : date-time ; se référer à l'annexe 2
Description : La propriété creationdate devrait être définie pour toute ressource conforme à DAV.  Quand elle est présente, elle contient le cachet de la date de création de la ressource (définie comme étant le moment à partir duquel son état n'était plus nul).
Modèle de contenu : <!ELEMENT creationdate (#PCDATA) >

13.2 Propriété displayname

Nom : displayname
Espace de noms : DAV:
Objet : Contient un nom de ressource qui soit adapté à la lecture par un utilisateur.
Description : La propriété displayname devrait être définie pour toute ressource conforme à DAV.  Quand elle existe, la propriété contient une description de la ressource adaptée à sa présentation à un utilisateur.
Modèle de contenu : <!ELEMENT displayname (#PCDATA) >

13.3 Propriété getcontentlanguage

Nom : getcontentlanguage
Espace de noms : DAV:
Objet : Contient l'entête Content-Language retournée en réponse à un GET sans entête accept
Description : La propriété getcontentlanguage DOIT être définie pour toute ressource conforme à DAV qui retourne l'entête Content-Language suite à un GET.
Valeur : language-tag ; language-tag est défini à la section 14.13 de [RFC2068]
Modèle de contenu : <!ELEMENT getcontentlanguage (#PCDATA) >

13.4 Propriété getcontentlength

Nom : getcontentlength
Espace de noms : DAV:
Objet : Contient l'entête Content-Length retournée en réponse à un GET sans entête accept.
Description : La propriété getcontentlength DOIT être définie pour toute ressource conforme à DAV qui retourne l'entête Content-Length en réponse à un GET.
Valeur : content-length ; Voir la section 14.14 of [RFC2068]
Modèle de contenu : <!ELEMENT getcontentlength (#PCDATA) >

13.5 Propriété getcontenttype

Nom : getcontenttype
Espace de noms : DAV:
Objet : Contient l'entête Content-Type retournée en réponse à un GET sans entête accept.
Description : Cette propriété getcontenttype DOIT être définie pour toute ressource conforme à DAV qui retourne l'entête Content-Type en réponse à un GET.
Valeur : media-type ; Définie à la section 3.7 de [RFC2068]
Modèle de contenu : <!ELEMENT getcontenttype (#PCDATA) >

13.6 Propriété getetag

Nom : getetag
Espace de noms : DAV:
Objet : Contient l'entête ETag retournée en réponse à un GET sans entête accept.
Description : La propriété getetag DOIT être définie pour toute ressource conforme à DAV qui retourne l'entête Etag.
Valeur : entity-tag ; Définie à la section 3.11 de [RFC2068]
Modèle de contenu : <!ELEMENT getetag (#PCDATA) >

13.7 Propriété getlastmodified

Nom : getlastmodified
Espace de noms : DAV:
Objet : Contient l'entête Last-Modified retournée en réponse à un GET sans entête accept.
Description : Remarquez que la date de dernière modification d'une ressource peut être le reflet de changements à n'importe quel endroit de la ressource, pas nécessairement un changement qui serait seulement consécutif à un GET.  Par exemple, le changement d'une propriété peut, à lui seul, provoquer le changement de la date de dernière modificationa. La propriété getlastmodified DOIT être définie pour toute ressource conforme à DAV qui renvoie l'entête Last-Modified en réponse à un GET.
Valeur : HTTP-date ; Définie à la section 3.3.1 of [RFC2068]
Modèle de contenu : <!ELEMENT getlastmodified (#PCDATA) >

13.8 Propriété lockdiscovery

Nom : lockdiscovery
Espace de noms : DAV:
Objet : Décrit les verrous actifs des ressources
Description : La propriété lockdiscovery retourne une liste des ressources qui ont un verrou, de quel type de verrou il s'agit, le type de limite de temps et le temps restant avant expiration du temps limite, et le marqueur de verrou associé.  Le serveur est libre de cacher toute ou partie de cette information si le demandeur qui en fait la demande n'a pas les privilèges suffisants pour voir les données demandées.
Modèle de contenu : <!ELEMENT lockdiscovery (activelock)* >

13.8.1 Exemple - Obtenir la propriété lockdiscovery

>>Requête

PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml; charset="utf-8"

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D='DAV:'>
     <D:prop><D:lockdiscovery/></D:prop>
   </D:propfind>

>>Réponse

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D='DAV:'>
     <D:response>
          <D:href>http://www.foo.bar/container/
          <D:propstat>
               <D:prop>
                    <D:lockdiscovery>
                         <D:activelock>
                              <D:locktype><D:write/></D:locktype>
                              <D:lockscope><D:exclusive/></D:lockscope>
                              <D:depth>0</D:depth>
                              <D:owner>Jane Smith</D:owner>
                              <D:timeout>Infinite</D:timeout>
                              <D:locktoken>
                                   <D:href>opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href>                               </D:locktoken>
                         </D:activelock>
                    </D:lockdiscovery>
               </D:prop>
               <D:status>HTTP/1.1 200 OK</D:status>
          </D:propstat>
     </D:response>
   </D:multistatus>

Cette ressource a un seul verrou exclusif en écriture, avec une limite de temps infinie.

13.9 Propriété resourcetype

Nom : resourcetype
Espace de noms : DAV:
Objet : Spécifie la nature de la ressource.
Description : La propriété resourcetype DOIT être définie pour toute ressource conforme à DAV.  La valeur par défaut est vide.
Modèle de contenu : <!ELEMENT resourcetype ANY >

13.10 Propriété source

Nom : source
Espace de noms : DAV:
Objet : La propriété source permet de connaître la ressource qui contient la source du lien avant son traitement.
Description : La source du lien (src) est typiquement l'URI de la ressource de sortie sur laquelle le lien est défini, et il n'y a, en général, qu'une seule destination (dst) à ce lien, qui est l'URI à laquelle la source non traitée de la ressource peut être accédée. Quand plus d'un lien de destination existe, cette spécification n'introduit pas de politique d'ordonnancement.
Modèle de contenu : <!ELEMENT source (link)* >

13.10.1 Exemple - une propriété source

   <?xml version="1.0" encoding="utf-8" ?>
   <D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/">
     <D:source>
          <D:link>
               <F:projfiles>Source</F:projfiles>
               <D:src>http://foo.bar/program</D:src>

               <D:dst>http://foo.bar/src/main.c</D:dst>
          </D:link>
          <D:link>
               <F:projfiles>Library</F:projfiles>
               <D:src>http://foo.bar/program</D:src>
               <D:dst>http://foo.bar/src/main.lib</D:dst>
          </D:link>
          <D:link>
               <F:projfiles>Makefile</F:projfiles>
               <D:src>http://foo.bar/program</D:src>
               <D:dst>http://foo.bar/src/makefile</D:dst>
          </D:link>
     </D:source>
   </D:prop>

Dans cet exemple, la ressource http://foo.bar/program a une propriété source qui contient trois liens. Chaque lien contient trois éléments, deux (src et dst) font partie du schéma DAV défini dans le présent document et l'un (projfiles) est définie dans le schéma http://www.foocorp.com/project/ (Source, Library, et Makefile). Un client qui n'implémenterait que les éléments de la spécification DAV ne comprendrait pas les éléments du schéma foocorp et les ignorerait, ne voyant ainsi que les les liens source et destination. Un client plus évolué, capable d'exploiter les éléments du schéma foocorp, serait capable de présenter à l'utilisateur plus d'informations relatives aux liens. Cet exemple démontre la puissance du balisage XML, qui permet aux valeurs d'éléments d'être exploitées ou non en fonction des capacités des clients.

13.11 Propriété supportedlock

Nom : supportedlock
Espace de noms : DAV:
Objet : Propriété utilisée pour obtenir la liste des possibilités de vérouillage supportées par la ressource.
Description : La propriété supportedlock d'une ressource retourne une liste des combinaisons des types d'accès et de portée qui peuvent être spécifiées dans une requête de vérouillage sur une ressource. Remarquez que les contenus réels sont eux-mêmes contrôlés par des contrôles d'accès de manière à ce qu'un serveur ne soit jamais tenu de communiquer une information à un client qui ne serait pas autorisé à la recevoir.
Modèle de contenu : <!ELEMENT supportedlock (lockentry)* >

13.11.1 Exemple - obtenir la propriété supportedlock

>>Requête

PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml; charset="utf-8"

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D="DAV:">
     <D:prop><D:supportedlock/></D:prop>
   </D:propfind>

>>Réponse

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:">
     <D:response>
          <D:href>http://www.foo.bar/container/</D:href>
          <D:propstat>
               <D:prop>
                    <D:supportedlock>
                         <D:lockentry>
                              <D:lockscope><D:exclusive/></D:lockscope>
                              <D:locktype><D:write/></D:locktype>
                         </D:lockentry>
                         <D:lockentry>
                              <D:lockscope><D:shared/></D:lockscope>
                              <D:locktype><D:write/></D:locktype>
                         </D:lockentry>
                    </D:supportedlock>
               </D:prop>
               <D:status>HTTP/1.1 200 OK</D:status>
          </D:propstat>
     </D:response>
   </D:multistatus>

14 Instructions pour le traitement de XML dans DAV

Toute ressource conforme DAV DOIT ignorer tout élément XML inconnu et tous ces enfants rencontrés pendant le traitement d'une méthode DAV utilisant XML comme langage de commande.

Cette restriction s'applique également au traitement, par des clients, de valeurs de propriétés DAV dans lesquelles les éléments XML inconnus DOIVENT être ignorés à moins que le modèle de la propriété en décide autrement.

Cette restriction ne s'applique pas à l'initialisation de propriétés DAV mortes sur le serveur pour lesquelles le serveur DOIT enregistrer les éléments XML inconnus.

De plus, cette restriction ne s'applique pas à l'utilisation d' XML quand il se trouve que XML est le type de contenu du corps de l'entité, par exemple, quand il est utilisé dans le corps d'un PUT.

Puisque que XML peut être transporté sous les types text/xml ou application/xml, un serveur DAV DOIT accepter les requêtes des méthodes DAV ayant des paramètres XML déclarés de types text/xml ou application/xml, et un client DAV DOIT accepter des réponses XML exprimées sous la forme de types text/xml ou application/xml.

15 Classes conformes à DAV

Il existe deux classes de conformité à DAV. Un client peut découvrir les classes de conformité d'une ressource en exécutant la méthode OPTIONS sur la ressource, et en examinant l'entête "DAV" qui est alors retourné.

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

Les classes de conformité ne se suivent pas nécessairement de manière linéaire. Une ressource qui est conforme à la classe 2 DOIT aussi être conforme à la classe 1 ; mais si des classes de conformité complémentaires sont définies ultérieurement, une ressource qui est conforme aux classes 1, 2, et 4 pourrait très bien ne pas être conforme à la classe 3. Remarquez aussi que les nombres ne sont pas les seuls identifiants possibles des classes de conformité.

15.1 Classe 1

Une ressource conforme de classe 1 DOIT satisfaire à toutes les exigences de toutes les sections de ce document.

Une ressource conforme de classe 1 DOIT retourner, au minimum, la valeur "1" dans l'entête DAV de réponse à la méthode OPTIONS.

15.2 Classe 2

Une ressource conforme de classe 2 DOIT satisfaire toutes les conditions de classe "1" et supporter la méthode LOCK, la propriété supportedlock, la propriété lockdiscovery, l'entête de réponse Time-Out et l'entête de requête Lock-Token. Une ressource conforme de classe "2" DEVRAIT aussi supporter l'entête de requête Time-Out et l'élément XML owner.

Les ressources conformes de classe "2" DOIVENT retourner, au minimum, les valeurs "1" et "2" dans l'entête DAV de réponse à la méthode OPTIONS.

16 Considérations sur l'internationalisation

Au royaume de l'internationalisation, cette spécification est conforme avec la politique de l'IETF sur les jeux de caractères [RFC2277]. Dans cette spécification, des champs humainement lisibles peuvent être trouvés soit sous la forme de valeurs de propriétés, soit de messages d'erreur retournés dans le corps d'une entité réponse. Dans les deux cas, le contenu humainenement lisible est codé en utilisant XML, qui donne très précisément les règles de balisage et d'encodage des jeux de caractères, et exige des processeurs XML qu'ils sachent lire des éléments XML codés, au minimum, en utilisant l'UTF-8 [UTF-8] du niveau multilangue de l'ISO 10646. Les exemples XML de cette spécification montrent l'utilisation du paramètre charset de l'entête Content-Type, tel que défini dans [RFC2376], tout comme l'attribut encoding de XML, qui permettent aux processeurs MIME et XML d'identifier le jeu de caractères utilisé.

XML fournit aussi la possibilité de balisage du langage permettant de spécifier le langage utilisé dans le contenu spécifique d'un élément XML. XML utilise soit les balises de langue déposées à l'IANA (se référer à [RFC1766]) soit les balises de langue de l'ISO 639 [ISO-639] dans l'attribut "xml:lang" de tout élément XML et qui permet d'en identifier la langue utilisée tant au niveau de son contenu que de ses attributs.

Les applications WebDAV DOIVENT supporter les balises relatives aux jeux de caractères, l'encodage des caractères, et les fonctionnalités des balises relativess aux langues de la spécification XML. Les développeurs d'applications WebDav sont fortement encouragés à lire "XML Media Types" [RFC2376] pour connaître les instructions sur l'utilisation des types MIME pour le transport des données XML, et sur l'utilisation du paramètre charset de l'entête Content-Type.

Les noms utilisés dans cette spécification se décomposent en trois catégories: les noms des éléments du protocole telles que ceux des méthodes et des entêtes, les noms d'éléments XML, et les noms de propriétés. Le nommage des éléments du protocole suit ce qui a déjà été fait pour HTTP, utilisant des noms anglais codés en ASCII américain pour les méthodes et les entêtes. A partir du moment où ces éléments du protocole sont invisibles aux utilisateurs, et ne sont, en fait, que de simples identifiants d'unités lexicales longues, ils n'ont pas besoin de supporter plusieurs types d'encodages de caractères. De la même manière, même si les noms des éléments XML utilisés dans cette spécification sont anglais et encodés en UTF-8, ils sont invisibles pour les utilisateurs, et n'ont donc pas besoin de supporter plusieurs sortes d'encodage de caractères.

Le nom d'une propriété définie sur une ressource est une URI. Bien que quelques applications (par exemple, un visualiseur de propriétés générique) affichera les URI des propriétés directement aux utilisateurs, on s'attend à ce que la plupart des applications utilisent un ensemble stable de propriétés, et fourniront des correspondances entre l'URI d'un nom de propriété et un champ humainement lisible pour les besoins de l'affichage aux utilisateurs. C'est seulement dans le cas où l'ensemble des propriétés est inconnu à l'avance qu'une application ne pourra faire autrement que de présenter aux utilisateur les URI des noms des propriétés. Nous recommandons que les applications fournissent, chaque fois que cela est possible, des noms humainement lisibles de propriétés.

Pour les comptes-rendus d'erreurs, nous suivons la convention des codes d'état de HTTP/1.1, incluant avec chaque code d'état une brève description en anglais du code (par exemple 423 (Locked)). Alors qu'il est possible qu'un programme utilisateur n'ayant pas un développement poussé se contente d'afficher ce message à l'utilisateur, les applications internationales le remplaceront par un message circonstancié, traduit dans la langue natale de l'utilisateur et en utilisant le jeu de caractère adéquate.

Puisque les traitements entre les serveurs et les clients n'exige pas que l'information soit localisée, cette spécification ne précise aucun mécanisme de transmission d'une telle information.

17 Considérations sur la sécurité

Cette section contient des considérations détaillées quant à la sécurité et leurs conséquences sur les applications WebDav développées.

Toutes les considérations sur la sécurité de HTTP/1.1 (discutées dans [RFC2068]) et XML (discutées dans [RFC2376]) s'appliquent également à WebDAV. De plus, les risques inhérents à la rédaction à distance exige une technologie d'authentication plus forte, introduit quelques nouveaux problèmes de confidentialité, et peut accroître les risques avec les serveurs mal conçus. Ces considérations sont discutées ci-dessous.

17.1 Authentification des clients

Par leur caractéristique principale qui est d'assurer des fonctions orientées sur la rédaction, les serveurs WebDav ont besoin d'utiliser des techniques d'authentification pour protéger pas seulement l'accès a une ressource quelconque du réseau , mais également l'intégrité de cette même ressource. De plus, l'introduction des fonctions de verrouillage exige de supporter les mécanismes d'authentification.

Un mot de passe envoyé sur un canal non sécurisé et "en clair" est un moyen inadapté d'assurer la sécurité d'accès et d'intégrité d'une ressource puisque ce mot de passe pourrait être intercepté. Puisque l'authentification de base d'HTTP/1.1 effectue essentiellement une transmission en clair du mot de passe, une simple authentication NE DOIT PAS être utilisée pour authentifier un client WebDav à un server sauf en cas de connection sécurisée. De plus, un serveur WebDav NE DOIT PAS envoyer de simples certificats d'authentification dans une entête d'authentification WWW à moins que la connection ne soit sécurisée. Des exemples de connections sécurisées sont les systèmes "Transport Layer Security (TLS)" employant une série de chiffres forts avec authentification mutuelle du client et du serveur, ou une connection sur un réseau qui est physiquement sécurisé, par exemple, un réseau isolé dans un immeuble avec des droits d'accès restreints.

Les applications WebDAV DOIVENT supporter le schéma d'authentification Digest [RFC2069]. Puisque le système d'authentification Digest vérifie que les deux parties d'une communication connaissent un secret partagé, un mot de passe, sans avoir à l'échanger en clair, l'authentification Digest évite les problèmes de sécurité inhérents à l'authentification simple tout en fournissant un niveau d'authentication qui soit utile dans un grand nombre de cas.

17.2 Blocage du service

Les attaques par blocage du service doivent être un sujet d'attention particulier pour les serveurs WebDav. WebDAV avec HTTP permettent ce genre d'attaques à plusieurs niveaux des ressources du système.

La mémoire sous-jacente peut être attaquée en déposant par PUT des fichiers extrêmement grands.

Demander des opérations récursives sur des grandes collections peut être une attaque contre les temps de traitement afin de dégrader les performances.

Construire plusieurs requêtes enchaînées les unes derrière les autres sur plusieurs connections peut être une attaque contre les connections du réseau.

Les serveurs WebDAV ont besoin d'être protégés à tous les niveaux contre ces tentatives de blocage du service.

17.3 La sécurité par l'obscurité

WebDAV fournit, au travers de la méthode PROPFIND, un mécanisme permettant de lister les ressources membres d'une collection. Cela diminue grandement l'efficacité des techniques de sécurité et de confidentialité qui s'appuient sur la difficulté à trouver le nom des ressources d'un réseau. Les utilisateurs de serveurs WebDav sont encouragés à utiliser des techniques de contrôle d'accès afin de prévenir tout accès indésirable aux ressources, plutôt que de s'appuyer sur le seul masquage du nom des ressources.

17.4 Considérations sur la confidentialité par rapport aux verrous

Quand on soumet une requête de verrouillage, un agent utilisateur peut aussi permettre de soumettre un champ XML owner qui contient l'information de contact de la personne qui retirera le verrou (pour les cas où une personne, plutôt qu'un robot, retirerait le verrou). Cette information de contact est enrégistrée dans la propriété lockdiscovery de la ressource, et peut être utilisée par d'autres collaborateurs pour entamer une négociation d'accès à la ressource. Toutefois, dans de nombreux cas, cette information de contact peut et doit rester privée. Les serveurs DEVRAIENT limiter l'accès en lecture à la propriété lockdiscovery que dans des cas appropriés. De plus, les agents utilisateurs DEVRAIENT fournir un moyen permettant de contrôler si l'information de contact doit être envoyée totalement, et que si elle est envoyée, contrôler exactement ce qui est envoyé.

17.5 Considérations sur la confidentialité par rapport aux propriétés

Puisque les valeurs de propriétés sont typiquement utilisées pour stocker de l'information telle que le nom de l'auteur du document, il y a là une possibilité pour que des problèmes de confidentialité apparaîssent à cause des possibilités d'accès extrêmement larges aux données des propriétés des ressources. Pour réduire le risque de divulgation intempestive d'information privée via les propriétés, les serveurs sont encouragés à développer des politiques d'accès qui séparent les droits d'accès en lecture au corps de la ressource de celui de lecture de ses propriétés. Cela permet à un utilisateur de contrôler la diffusion des données des propriétés sans pour autant devoir réduire les droits d'accès à la ressource elle-même.

17.6 Réduction de la sécurité à cause des liens de type source

HTTP/1.1 est protégé contre le risque d'attribution de droits d'accès en lecture à des codes scripts parce qu'ils peuvent contenir des informations sensibles. D'ores et déjà, WebDAV, au travers de sa fonction de lien source, peut potentiellement fournir une URI à des ressources script pour qu'elles puissent être écrites. Avec HTTP/1.1, un serveur pouvait raisonnablement protéger l'accès aux ressources sources à cause de la prédominence des accès de type "lecteure seule". WebDAV, avec son orientation franchement marquée pour la rédaction, encourage les accès en lecture/écriture sur les ressources, et fournit la fonction de lien source pour identifier la source. Cela réduit les bénéfices de la sécurité qui consistait à empêcher l'accès aux ressources source. Les utilisateurs et les administrateurs des serveurs WebDav doivent être très vigilents quand ils autoriseront la rédaction à distance de scripts, limitant les accès en lecture et écriture aux ressources source aux seuls demandeurs autorisés.

17.7 Conséquences de l'usage d'entités XML externes

XML supporte une fonctionalité connue sous le nom "entités externes", définie à la section 4.2.2 de [REC-XML], qui signifie au processeur XML d'aller chercher et d'inclure un fragment XML se trouvant à une URI particulière. Une entité XML externe peut être utilisée pour ajouter un morceau ou modifier une Déclaration de Type de Document (DTD) associée à un document XML. Une entité XML externe peut également être utilisée pour inclure un contenu XML à l'intérieur d'un document XML. En ce qui concernen les fragments XML non-validant, comme par exemple le XML utilisé dans cette spécification, l'inclusion d'entités externes XML n'est pas une exigence de [REC-XML]. Toutefois, [REC-XML] dit clairement qu'un processeur XML peut, à sa discrétion, inclure l'entité XML externe.

Les entités externes XML n'ont pas de fiabilité intrinsèque et sont sujettes à toutes les attaques qui sont endémiques à toute requête GET HTTP. Plus encore, une entité XML externe peut modifier la DTD, et finalement affecter la forme finale d'un document XML, dans le pire des cas, elle peut modifier de façon significative sa sémantique, ou exposer le processeur XML aux risques concernant la sécurité discutés dans [RFC2376]. Par conséquence, les développeurs DOIVENT être avertis que les entités XML externes qui peuvent être traitées ne sont pas fiables.

Il y a également un risque d'échelle qui arriverait si une application largement déployée faisait l'usage d'entité XML externes. Dans ce cas, il est possible qu'il puisse y avoir un nombre significatif de requêtes pour une seule et même entité XML externe, cela pouvant potentiellement surcharger tout serveur génèrant des requêtes pour la ressource contenant l'entité XML externe.

17.8 Risques en relation avec les marqueurs de verrous

Cette spécification, dans sa section 6.4, exige l'utilisation des Identifiants Uniques Universel (Universal Unique Identifiers -UUID-) pour les marqueurs de verrous, afin de garantir leur unicité dans le temps et l'espace. Les UUIDs, tels que définis dans [ISO- 11578], contiennent un champ "node" qui "consiste en l'adresse IEEE, qui, d'habitude, est celle de l'ordinateur. Pour les systèmes qui ont plusieurs noeuds IEEE 802, toute adresse disponible de noeud peut être utilisée." Puisqu'un serveur WebDav produira beaucoup de verrous au cours de sa vie, la conséquence est qu'il va aussi publiquement exposer ses addresses IEEE 802.

Il y a plusieurs risques consécutifs à l'exposition d'adresses IEEE 802. En utilisant les adresses IEEE 802 :

Dans la section 6.4.1 de cette spécification, on y détaille un mécanisme altérnatif pour générer le champs "node" d'une UUID sans utiliser une adresse IEEE 802, ce qui allège les risques associés à l'exposition des adresses IEEE 802 par utilisant d'une source alternative d'unicité.

18 Considérations IANA

Ce document définit deux espaces de noms, l'un s'applique aux noms de propriétés l'autre aux éléments XML spécifiques à WebDav utilisés pour les valeurs des propriétés.

Des URIs sont utilisées dans les deux cas de figures et cela pour plusieurs raisons. L'usage d'une URI n'impose aucune démarche administrative de dépôt auprès d'un organisme officiel de nomage faisant autorité, donc cela permet aux utilisateurs de définir rapidement les noms des propriétés WebDav et des éléments XML utilisés par eux-mêmes ou des applications de WebDav. Les URI fournissent également un espace d'adressage unique garantissant que les utilisateurs distribués de WebDav n'auront aucune collision entre des noms de propriétés ou d'éléments XML qu'ils auront créés.

Cette spécification définit des ensembles distincts pour les noms de propriétés et les noms d'éléments XML qui sont compris par toutes les applications WebDav. Les noms des propriétés et des éléments XML de cette spécification sont tous dérivés de l'URI de base DAV: et en lui ajoutant un suffixe : par exemple "DAV:creationdate" pour la propriété "creationdate".

Cette spécification définit également un plan d'URI pour l'encodage des marqueurs de verrous : le plan d'URI opaquelocktoken décrit dans la section 6.4.

Pour garantir une intéropérabilité correcte basée sur cette spécification, IANA DOIT réserver les espaces de noms "DAV:" et "opaquelocktoken:" à l'usage de cette spécification, ses révisions, et les spécifications relatives à WebDav.

19 Propriété intellectuelle

La notice suivante a été copiée de RFC 2026 [RFC2026], section 10.4, et décrit la position de l'IETF concernant les réclamations de propriété intellectuelle qui pourraient concerner ce document.

L'IETF ne prend aucune position quant à la validité ou l'étendue d'une quelconque propriété intellectuelle ou autres droits qui pourraient être réclamés pour son implémentation ou utiliser d'autre technologie décrite dans ce document ou l'étendue à laquelle toute licence sous de tels droits pourrait ou ne pourrait pas être disponible ; ni même représente qu'un quelconque effort n'ait été fait pour identifier l'existence de tels droits. Les informations sur les procédures de l'IETF relatives au droits sur la documentation des standards eux mêmes ou leur documentation dérivée peuvent être trouvée dans le BCP-11. Les copies des réclamations de droits applicables aux publications ainsi que toute assurance de licences à rendre disponible, ou le résultat d'une tentative faite pour obtenir une licence générale ou la permission de pouvoir utiliser de tels droits de propriétés par les intégrateurs ou les utilisateurs de cette spécification peuvent être obtenus au secrétariat de l'IETF.

L'IETF invite toute personne intéressée à porter à son attention tous les droits d'auteurs, brevets ou applications de brevet, ou tout autre droit de propriété qui pourrait couvrir la technologie qui pourrait être requise pour mettre en pratique ce standard. Nous vous remercions dans ce cas d'adresser cette information au directeur Exécutif de l'IETF.

20 Remerciements

La réussite d'une spécification telle que celle-là repose sur les relectures attentives et critiques et dépérit en cas d'indifférence par négligence. Les auteurs expriment leur grande reconnaissance aux personnes qui ont contribué à son élaboration et dont les noms suivent, dont la perspicacité fut tellement appréciable à chaque étape de notre travail.

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, and Lauren Wood.

Nous réservons une mention spéciale à deux personnes parmi cette liste. Les contributions de Larry Masinter fut incalculable, à la fois en aidant à la création de ce groupe de travail et en guidant patiemment les auteurs tout au long de leur chemin. Il a tant de fois contribué à la mise en place de grands standards que cela nous aurait fait de la peine de ne pas le rencontrer. La contribution de Judith Slein qui a porté sur la clarification de l'expression de besoins, et dans sa relecture patiente brouillons après brouillons, les deux ont ainsi sensiblement contrinué à l'amélioration de cette spécification et nos ont permis d'augmenter notre connaissance sur la gestion des documents.

Nous aimerions également remercier John Turner pour le développement de la DTD XML.

21 Références

21.1 Références normatives

[RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee,T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[REC-XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen, "Extensible Markup Language (XML)." World Wide Web Consortium Recommendation REC-xml-19980210. http://www.w3.org/TR/1998/REC-xml-19980210.
[REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Namespaces in XML". World Wide Web Consortium Recommendation REC- xml-names-19990114. http://www.w3.org/TR/1999/REC- xml-names-19990114/
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P, Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP :  Digest Access Authentication", RFC 2069, January 1997.   
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.   
[ISO-639] ISO (International Organization for Standardization). ISO 639:1988. "Code for the representation of names of languages."   
[ISO-8601] ISO (International Organization for Standardization). ISO 8601:1988. "Data elements and interchange formats - Information interchange - Representation of dates and times."   
[ISO-11578] ISO (International Organization for Standardization). ISO/IEC 11578:1996. "Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)"   
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.   
[UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2279, January 1998.

21.2 Références informatives

[RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996.
[RFC1807] Lasher, R. and D. Cohen, "A Format for Bibliographic Records", RFC 1807, June 1995.
[WF]C. Lagoze, "The Warwick Framework: A Container Architecture for Diverse Sets of Metadata", D-Lib Magazine, July/August 1996. http://www.dlib.org/dlib/july96/lagoze/07lagoze.html  
[USMARC] Network Development and MARC Standards, Office, ed. 1994.
"USMARC Format for Bibliographic Data", 1994. Washington, DC: Cataloging Distribution Service, Library of Congress.
[REC-PICS] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS Label Distribution Label Syntax and Communication Protocols" Version 1.1, World Wide Web Consortium Recommendation REC-PICS-labels-961031. http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.
[RFC2291] Slein, J., Vitali, F., Whitehead, E. and D. Durand, "Requirements for Distributed Authoring and Versioning Protocol for the World Wide Web", RFC 2291, February 1998.
[RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin Core Metadata for Resource Discovery",
RFC 2413, September 1998.
[RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, July 1998.

22 Adresses des auteurs

Y Y. Goland

Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399

EMail: yarong@microsoft.com

E J. Whitehead, Jr.

Dept. Of Information and Computer Science
University of California, Irvine
Irvine, CA 92697-3425

EMail: ejw@ics.uci.edu

A Faizi

Netscape
685 East Middlefield Road
Mountain View, CA 94043

EMail: asad@netscape.com

S R. Carter

Novell
1555 N. Technology Way
M/S ORM F111
Orem, UT 84097-2399

EMail: srcarter@novell.com

D Jensen

Novell
1555 N. Technology Way
M/S ORM F111
Orem, UT 84097-2399

EMail: dcjensen@novell.com

23 Annexes

23.1 Annexe 1 - DTD de WebDav

Cette section fournit une Définition de Type de Documents, correspondant aux règles de [REC-XML], pour les éléments XML utilisés dans le flot du protocole et dans les valeurs des propriétés. Elle rassemble les définitions d'éléments données aux sections 12 et 13.

<!DOCTYPE webdav-1.0 [    <!--============ XML Elements from Section 12 ==================-->
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,    locktoken?) >
<!ELEMENT lockentry (lockscope, locktype) >
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
<!ELEMENT locktype (write) >
<!ELEMENT write EMPTY >
<!ELEMENT lockscope (exclusive | shared) >
<!ELEMENT exclusive EMPTY >
<!ELEMENT shared EMPTY >
<!ELEMENT depth (#PCDATA) >
<!ELEMENT owner ANY >
<!ELEMENT timeout (#PCDATA) >
<!ELEMENT locktoken (href+) >
<!ELEMENT href (#PCDATA) >
<!ELEMENT link (src+, dst+) >
<!ELEMENT dst (#PCDATA) >
<!ELEMENT src (#PCDATA) >
<!ELEMENT multistatus (response+, responsedescription?) >
<!ELEMENT response (href, ((href*, status)|(propstat+)),    responsedescription?) >
<!ELEMENT status (#PCDATA) >
<!ELEMENT propstat (prop, status, responsedescription?) >
<!ELEMENT responsedescription (#PCDATA) >

   <!ELEMENT prop ANY >
<!ELEMENT propertybehavior (omit | keepalive) >
<!ELEMENT omit EMPTY >
<!ELEMENT keepalive (#PCDATA | href+) >
<!ELEMENT propertyupdate (remove | set)+ >
<!ELEMENT remove (prop) >
<!ELEMENT set (prop) >
<!ELEMENT propfind (allprop | propname | prop) >
<!ELEMENT allprop EMPTY >
<!ELEMENT propname EMPTY >
<!ELEMENT collection EMPTY >    <!--=========== Property Elements from Section 13 ===============-->
<!ELEMENT creationdate (#PCDATA) >
<!ELEMENT displayname (#PCDATA) >
<!ELEMENT getcontentlanguage (#PCDATA) >
<!ELEMENT getcontentlength (#PCDATA) >
<!ELEMENT getcontenttype (#PCDATA) >
<!ELEMENT getetag (#PCDATA) >
<!ELEMENT getlastmodified (#PCDATA) >
<!ELEMENT lockdiscovery (activelock)* >
<!ELEMENT resourcetype ANY >
<!ELEMENT source (link)* >
<!ELEMENT supportedlock (lockentry)* >    ]>

23.2 Annexe 2 - Profiles de date et de jour ISO 8601

La propriété creationdate précise que l'ISO 8601 [ISO-8601] doit être utilisée pour formater la date . Cette section définit un profile de format de date de l'ISO 8601 pour une utilisation avec cette spécification. Ce profile est issu d'un brouillon Internet écrit par Chris Newman, qui est mentionné ici pour que son travail lui soit correctment attribué.

   date-time = full-date "T" full-time
   full-date = date-fullyear "-" date-month "-" date-mday
   full-time = partial-time time-offset
   date-fullyear = 4DIGIT
   date-month = 2DIGIT  ; 01-12
   date-mday = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 basé sur month/year
   time-hour = 2DIGIT  ; 00-23
   time-minute = 2DIGIT  ; 00-59
   time-second = 2DIGIT  ; 00-59, 00-60 basé sur des "leap second rules"
   time-secfrac = "." 1*DIGIT
   time-numoffset = ("+" / "-") time-hour ":" time-minute
   time-offset = "Z" / time-numoffset
   partial-time = time-hour ":" time-minute ":" time-second [time-secfrac]

Les décalages numériques sont calculés à partir de l'heure local moins l'UTC (Coordinated Universal Time). Aussi, l'heure équivalente en UTC peut être déterminée en soustrayant le décalage à l'heure locale. Par exemple, 18:50:00- 04:00 est la même chose que 22:58:00Z.

Si l'heure UTC est connue, mais que le décalage avec les heures locales ne l'est pas, cela peut être représenté avec undécalage de "-00:00". Cela est différent d'un décalage de "Z" impliquant que l'UTC est le point de référence préféré pour l'heure spécifiée.

23.3 Annexe 3 - Remarques sur le traitement des éléments XML

23.3.1 Remarques sur les éléments XML vides

XML supporte deux mécanismes pour indiquer que des éléments XML n'ont aucun contenu. Le premier consiste à déclarer un élément de telle sorte que son instanciation puisse être de la forme <A></A>. La deuxième consiste à déclarer un élément de type EMPTY qui s'utilisera sous la forme <A/>. Ces deux écritures d'éléments XML sont sémantiquement identiques. C'est une violation de la spécification XML que d'utiliser l'écriture de la forme <A></A> pour un élément déclaré EMPTY dans la DTD (c'est à dire <!ELEMENT A EMPTY>). Si une telle déclaration est présente dans la DTD, la forme <A/> est la seule autorisée. Si l'élément n'est pas déclaré avec un modèle de contenu EMPTY, alors n'importe laquelle des deux formes <A></A> ou <A/> est autorisée pour les instances vides de cet élément.

23.3.2 Remarques sur les traitements XML interdits

XML est un format de données flexible qui rend facile la soumission de données sous une forme qui semble apparement légale mais qui ne l'est pas en réalité. La "philosophie" du "Soit souple dans ce que tu acceptes mais strict dans ce que tu envoies" s'applique toujours, mais il NE DOIT PAS être appliquée de manière inappropriée. XML est extrêmement souple dans sa manière de considérer les espaces blancs, l'ordre des éléments, l'insertion de nouveaux éléments, etc... Cette souplesse n'impose de faire appel à aucune extension, particulièrement dans le domaine de la signification des éléments.

Il n'y a pas de gentillesse particulière à accepter des combinaisons illégales d'éléments XML. Au mieux, cela provoquera un résultat indésirable et au pire cela pourrait provoquer de réels dégâts.

23.3.2.1 exemple - Une erreur de syntaxe XML

Le corps de requête suivante d'une méthode PROPFIND est illégal.

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

La définition de l'élément propfind ne permet que d'utiliser l'un des éléments allprop ou propname, pas les deux en même temps. Aussi, le fragment ci-dessus est une erreur et DOIT provoquer en réponse l'émission du code d'erreur 400 (mauvaise requête).

Imaginez, toutefois, qu'un serveur souhaite être "sympathique" et décide de prendre l'élément allprop comme l'élément vrai de la requête et réponde. Un client travaillant avec une petite bande passante limitée et qui essaierait d'exécuter un propname serait très surpris de découvrir que le serveur a traité sa demande comme si il s'agissait d'un allprop.

De plus, si un serveur était indulgent et décidait de répondre à cette requête, les résultats varieraient de manière aléatoire d'un serveur à l'autre, les uns exécutants la directive allprop, et les autres exécutants la directive propname. Cela réduirait l'interopérabilité plutôt que cela ne l'augmenterait.

23.3.2.2 exemple - Elément XML inconnu

L'exemple précédent était illégal parce qu'il contenait deux éléments dont il était explcitiement spécifié qu'ils s'excluaient mutuellement. Toutefois, XML est un langage extensible, donc on peut imaginer que de nouveaux éléments peuvent être définis pour une utilisation avec propfind. Ci-dessous se trouve le corps de la requête d'un PROPFIND et, comme dans l'exemple précédent, DOIT être rejetée avec un code de retour 400 (mauvaise requête) par un serveur qui ne comprend pas l'élément expired-props.

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D="DAV:" xmlns:E="http://www.foo.bar/standards/props/">
     <E:expired-props/>
   </D:propfind>

Pour comprendre pourquoi un code de retour 400 (mauvaise requête) est retourné, il faut regarder le corps de la requête et comment le serveur, non-familier de l'élément expired-props, le considère.

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D="DAV:" xmlns:E="http://www.foo.bar/standards/props/">
   </D:propfind>

Comme le serveur ne comprend pas l'élément expired-props, au sens des règles de traitement XML spécifiques à WEBDAV décrites dans la section 14, il doit l'ignorer. Ainsi, le serveur voit un élément propfind vide, qui, par définition de l'élément propfind est interdit.

Vous pouvez remarquez que si l'extension avait été ajoutée cela n'aura pas pour autant forcément provoqué l'émission du code de retour 400 (mauvaise requête). Par exemple, imaginez que le corps de requête suivant soit utilisé dans un PROPFIND:

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D="DAV:" xmlns:E="http://www.foo.bar/standards/props/">

     <D:propname/>
     <E:leave-out>*boss*</E:leave-out>
   </D:propfind>

L'exemple précédent contient un élément fictif leave-out. Son but est de prévoir le retour de toute propriété dont le nom correspondrait au motif soumis. Si l'exemple précédent était soumis à un serveur ne connaissant pas l'élément leave-out, le seul résultat obtenu serait que l'élément leave-out aurait été ignoré et qu'un propname aurait été exécuté.

23.4 Annexe 4 -- Les espaces de noms XML pour WebDAV

23.4.1 Introduction

Tout système conforme à DAV DOIT supporter les extensions d'espaces de noms XML en conformité avec la spécification [REC-XML-NAMES].

23.4.2 Signification des noms qualifiés

[Remarque au lecteur : Cette section n'existe pas dans [REC-XML-NAMES], mais elle est nécessaire pour éviter l'amboguïté avec les processeurs WebDav.]

Les programmes de traitement conformes à WebDAV DOIVENT interpréter un nom qualifié comme une URI construite en rajoutant la LocalPart à la fin de l'URI du nom de l'espace de noms.

Exemple :

   <del:glider xmlns:del="http://www.del.jensen.org/">
     <del:glidername>Johnny Updraft</del:glidername>
     <del:glideraccidents/>
   </del:glider>

Dans cette exemple, le nom de l'élément qualifié "del:glider" est interprété comme étant l'URL "http://www.del.jensen.org/glider".

   <bar:glider xmlns:bar="http://www.del.jensen.org/">
     <bar:glidername>Johnny Updraft</bar:glidername>
     <bar:glideraccidents/>
   </bar:glider>

Même si cet exemple est syntaxiquement différent du précédent, il est sémantiquement égal. Chaque instance du nom de l'espace de nom "bar" est remplacée par "http://www.del.jensen.org/" qui est rajouté au nom local de chaque nom d'élément. Les noms de balises résultants dans cet exemple seront exactement les mêmes que dans l'exemple précédent.

   <foo:r xmlns:foo="http://www.del.jensen.org/glide">
     <foo:rname>Johnny Updraft</foo:rname>
     <foo:raccidents/>
   </foo:r>

Cet exemple est également sémantiquement égal aux deux précédents. Chaque instance du nom de l'espace de noms "foo" est remplacée par l'URL "http://www.del.jensen.org/glide" qui est ensuite ajoutée au nom local de chaque nom de balise, les noms de balises résultant sont identiques à ceux des exemples précédents.

24 Copyright complet

Copyright (C) The Internet Society (1999). Tous droits réservés.

Ce document et ses traductions peuvent être copiés et transmis à d'autres personnes, et des travaux dérivés afin de le commenter ou lui rajouter des explications ou aider à son implémentation peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d'une quleconque nature, à condition que la mention de copyright ci-dessus et ce paragraphe soient inclus sur toutes ces copies et travaux dérivés. Toutefois, ce document lui-même ne peut pas être modifié d'aucune façon, comme par exemple en retirant le copyright ou les références à "the Internet Society" ou d'autres organisaitons Internet, excepté quand cela est justifié pour le développement des standards Internet auquel cas les procédures concernant les copyrights définies dans les processus de production des standards Internet (the Internet Standards process) DOIVENT être respectés, ou comme cela est requis de les traduire en d'autres langages que l'anglais.

La permission limitée qui est accordée ci-dessus sont perpétuelles et ne seront pas révoquées par "the Internet Society" ou ses successeurs ou ses assignés.

Ce dcoument et l'information qu'il contient ci-dessus est fourni sur une base "TEL QUEL" et "THE INTERNET SOCIETY" ET "THE INTERNET ENGINEERING TASK FORCE" SE DESENGAGENT DE TOUTE GARANTIE, EXPRES OU IMPLICITE, INCLUANT SANS TOUTEFOIS ETRE LIMITEE A TOUTE GARANTIE QUE L'UTILISATION DE L'INFORMATION CI-DESSUS N'ENFREINDRA PAS DES DROITS OU TOUTE GARANTIE CONSECUTIVE DE TYPE COMMERCIALE OU D'ADEQUATION POUR UN USAGE PARTICULIER QUEL QU'IL SOIT.