�

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.

Traducteurs :

Jean-Jacques Thomasson : <[email protected]>

Traduction h�berg�e par <XML>fr.

Note de traduction: L'entit� ISO LATIN I de "oe" ligatur� n'�tant pas support�e par certains navigateurs, il sera �crit 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, <[email protected]>
E J. Whitehead, Jr., University of California, <[email protected]>
A Faizi,� Netscape, <[email protected]>
D Jensen, Novell, <[email protected]>

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 :

En ce qui concerne les propri�t�s : pouvoir cr�er, supprimer et obtenir des informations sur des pages WEB, tel que le nom de leurs auteurs, leurs dates de cr�ation, et pouvoir lier des pages entre elles, quelque en soit le format.
En ce qui concerne les collections : pouvoir cr�er des ensembles de documents et obtenir une liste hi�rarchique des membres (� la mani�re d'une arborescence de r�pertoires et de fichiers).
En ce qui concerne le verrouillage : pouvoir garantir l'unicit� d'acc�s � un document (pas plus d'une personne au m�me moment) pour �viter le probl�me de "derni�re modification perdue", qui survient quand des auteurs successifs travaillent sur des copies d'un m�me document sans fusionner � la fin leurs modifications respectives.
Les op�rations sur les espaces de noms : La possibilit� de dire au serveur de copier ou d�placer des ressources WEB.

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 :

le pourcentage de m�moire utilis�
la taille de la m�moire en octets
la taille de la m�moire libre en octet
la taille des fichiers de pagination ou de swap en octets
l'espace libre, en octets, des fichiers de pagination ou de swap
la taille totale, en octets, de l'espace d'adressage virtuel d'un utilisateur
la taille totale, en octets, de l'espace d'adressage d'un utilisateur
La taille disque, en octets, du pilote de d�marrage
l'espace disque libre, en octets, du pilote de d�marrage
l'heure courante
la quantit� de temps �coul�e depuis que le syst�me a �t� d�marr�
la taille individuelle de diff�rents fichiers
les dates de cr�ation, dernier acc�s, et derni�re modification des fichiers dans diff�rents r�pertoires syst�me
diff�rents param�tres d'utilisation des ressoures syst�me
la position courante du curseur de la souris
la position courante du point d'insertion
le nombre courant de processus ou de canaux en cours d'ex�cution
les identifiants ou les poign�es de la fen�tre du bureau et de la fen�tre active
la valeur du pointeur de pile de l'invit�
les identificants de processus et de canal d'invite
diff�rents compteurs d'activit� d�pendant de l'architecture sp�cifique du processeur

(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 :

http://www.foo.bar/boxschema/bigbox,
http://www.foo.bar/boxschema/author,
DAV:creationdate ,
DAV:displayname,
DAV:resourcetype ,
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 :

http://www.foo.bar/boxschema/bigbox (un autre cas d'instance du type de propri�t� "bigbox "),
DAV:creationdate,
DAV:displayname,
DAV:getcontentlength,
DAV:getcontenttype,
DAV:getetag,
DAV:getlastmodified,
DAV:resourcetype ,
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 :

http://www.foo.bar/boxschema/bigbox,
http://www.foo.bar/boxschema/author,
DAV:creationdate,
DAV:displayname,
DAV:resourcetype ,
DAV:supportedlock .

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

http://www.foo.bar/boxschema/bigbox,
DAV:creationdate,
DAV:displayname,
DAV:getcontentlength,
DAV:getcontenttype,
DAV:getetag,
DAV:getlastmodified,
DAV:resourcetype ,
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: ".

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 :

le serveur n'autorise pas la cr�ation de collections � l'emplacement indiqu� dans son espace de noms,
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 esthttp://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="[email protected]", 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="[email protected]", 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="[email protected]", 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="[email protected]", 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 protocoleDAV 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.0l'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 2³²-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 :

Il est possible de suivre le mouvement du mat�riel de sous-r�seaux en sous-r�seaux.
Il peut �tre possible d'identifier la fabricant du mat�riel ex�cutant un serveur WebDav.
Il peut �tre possible de d�terminer le nombre de chaque type d'ordinateur ex�cutant WebDav.

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: [email protected]

E J. Whitehead, Jr.

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

EMail: [email protected]

A Faizi

Netscape
685 East Middlefield Road
Mountain View, CA 94043

EMail: [email protected]

S R. Carter

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

EMail: [email protected]

D Jensen

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

EMail: [email protected]

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 [ ��  <!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 > ��  <!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

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.

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

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

Table des mati�res

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 Ressources de type collection

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

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 Mod�le d'URI de 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�s

7.4 Verrous d'�criture et ressources nulles

7.5 Verrous d'�criture et collections

7.6 Verrous d'�criture et ent�te de requ�te If

7.6.1 Exemple - verrou d'�criture

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

7.8 Rafra�chissement des verrous d'�criture

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

8.1 La 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.1 Codes d'�tats � utiliser avec des m�thodes � �tats multiples 207

8.2.2 Exemple - PROPPATCH

8.3 M�thode MKCOL

8.3.1 Requ�te

8.3.2 Codes d'�tats

8.3.3 exemple - MKCOL

8.4 M�thodes GET et HEAD appliqu�es � des collections

8.5 La 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.6.2.1 Exemple - DELETE

8.7 M�thode PUT

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

8.7.2 M�thode PUT appliqu�e � des collections

8.8 La 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 d'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'�tats

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 de 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

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

6.4 Mod�le d'URI de marqueur de verrou `opaquelocktoken`

7.6 Verrous d'�criture et ent�te de requ�te `If`

7.7 Verrous d'�critre et m�thode `COPY/MOVE`

8.1 La m�thode `PROPFIND`

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.1 Codes d'�tats � utiliser avec des m�thodes � �tats multiples `207`

8.2.2 Exemple - `PROPPATCH`

8.3 M�thode `MKCOL`

8.3.3 exemple - `MKCOL`

8.4 M�thodes `GET` et `HEAD` appliqu�es � des collections

8.5 La 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.6.2.1 Exemple - `DELETE`

8.7 M�thode `PUT`

8.7.1 M�thode `PUT` pour des ressources autres que des collections

8.7.2 M�thode `PUT` appliqu�e � des collections

8.8 La 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.6 exemple - `COPY` avec `Overwrite`

8.8.7 exemple - `COPY` sans `Overwrite`

8.8.8 exemple - `COPY` d'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.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.4 Valeur de `Depth` et verrouillage

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.1.1 Exemple - Ent�te `IF` avec un `No-tag-list`

9.4.2 R�gle de production de `Tagged-list`

9.4.2.1 Exemple - ent�te `If` avec `Tagged-List`

9.4.3 r�gle de production de `not`

9.4.4 Fonction `Matching`

9.4.5 Ent�te `If` et les proxies non conformes � DAV

9.5 Ent�te `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.1 Code d'�tat `102` : traitement

10.2 Code d'�tat `207` : �tats multiple

10.3 Code d'�tat `422` : entit� impossible � traiter

10.4 Code d'�tat `423` : verrouill�

10.5 Code d'�tat `424` : �chec de d�pendance

10.6 Code d'�tat `507` : m�moire insuffisante

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.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.1.1 El�ment XML `propstat`

12.9.1.2 El�ment XML `status`

12.9.2 El�ment XML `responsedescription`