|
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
Ce document décrit une extension du protocole HTTP/1.1 qui permet aux clients WEB de participer à des processus éditoriaux à distance. Cette extension fournit un ensemble cohérent de méthodes, entêtes, formats de corps de requêtes et de réponses qui permettent de faire les opérations suivantes :
Le raisonnement et les conditions requises pour ces opérations sont décrits dans un document annexe intitulé "Conditions nécessaires au protocole d'écriture et de versionnement distribués pour le World Wide Web" [RFC2291].
Les sections ci-dessous forment une introduction détaillée aux propriétés des ressources (section 4), les collections de ressources (section 5), les opérations de verrouillage (section 6). Ces sections introduisent les abstractions manipulées par les méthodes HTTP spécifiques à WebDav décrites à la section section 8, "méthodes HTTP pour l'écriture distribuée".
Dans HTTP/1.1, les paramètres passés aux méthodes étaient exclusivement codés dans les entêtes HTTP. WebDav, au contraire, code ces informations soit dans le corps d'une entité requête en utilisant le format XML (eXtensible Markup Language) [REC-XML], soit dans une entête HTTP. Le choix de l'utilisation de XML pour coder les paramètres d'une méthode a été motivé par la possibilité qu'offre ce langage de pouvoir rajouter des éléments à des structures existantes, apportant ainsi l'extensibilité attendue et par la possibilité qu'offre XML de pouvoir coder l'information en utilisant les jeux de caractères ISO 10646, afin de garantir un support international. Comme règle générique, on retiendra que les paramètres sont codés dans le corps XML des requêtes quand leur longueur est quelconque, ou qu'ils peuvent être vus par un regard humain, ce qui nécessite un codage des caractères en ISO 10646 et qu'ils sont codés à l'intérieur des entêtes HTTP dans les autres cas. La section 9 décrit les nouvelles entêtes HTTP utilisées avec les méthodes WebDAV.
Au delà de son utilisation pour le codage des paramètres des méthodes, XML est utilisé dans WebDav pour coder les réponses aux méthodes, apportant ainsi les avantages de l'extensibilité et de l'internationalisation de XML dans les deux cas de figure.
Les éléments XML utilisés dans cette spécification sont définis dans la section 12.
L'extension de l'espaces de noms XML (Annexe 4) est aussi utilisée dans cette spécification afin d'autoriser l'usage de nouveaux éléments XML sans que ceux-là rentrent en collision avec d'autres.
Bien que les codes d'états fournis par HTTP/1.1 soient suffisants pour prendre en charge la plupart des cas d'erreur des méthodes WebDAV, il existe quelques cas d'erreurs qui ne tombent pas nettement dans les catégories existantes. Les nouveaux codes d'états développés pour les méthodes WebDav sont définis dans la section 10. Comme il existe quelques méthodes WebDav qui peuvent agir sur plusieurs ressources, les réponses de type états multiples ont été introduites pour retourner des informations d'états concernant plusieurs ressources. La réponse d'états multiples est décrite dans la section 11.
WebDAV utilise le mécanisme des propriétés pour renregistrer l'état courant d'une ressource. Par exemple, qaund un verrou est posé sur une ressource, une propriété d'information de verrou permet de connaître l'état courant du verrou. La section 13 définit les propriétés utilisées avec les spécifications WebDAV.
La fin de la spécification contient des sections portant sur la compatibilité (section 15), sur le support de l'internationalisation (section 16), et la sécurité(section 17).
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].
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
.
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.
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.
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.
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.
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.
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.
opaquelocktokenLe 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]
Les UUIDs, tels que défini dans [ISO-11578], contiennent un champ "noeud" qui contient une des adresses IEEE 802 du serveur. Comme il est dit dans la section 17.8, il y a plusieurs risques relatifs à la sécurité inhérents à l'exposition des adresses IEEE 802 des machines. Cette section fournit un mécanisme alternatif qui permet de générer le champ "noeud" d'un UUID sans utiliser l'adresse IEEE 802. Les serveurs WebDav PEUVENT utiliser cet algorithme pour la création du champ noeud au moment de la génération des UUIDs. Le texte de cette section est issu d'un brouillon sur Internet de Paul Leach et Rich Salz, dont les noms sont rappelés ici afin que leurs travaux soient reconnus comme il se doit.
La solution idéale est d'obtenir un nombre aléatoire de 47 bits de qualité cryptographique, et de l'utiliser comme formant les 47 bits basses de l'ID du noeud, avec le bit de poids fort du premier octet de l'ID du noeud égal à 1. Ce bit est celui réservé au typage unicast/multicast, jamais utilisé dans les adresses IEEE 802 pas les cartes réseaux ; par conséquent, il ne pourra jamais y avoir de conflit entre les UUIDs générés par les machines, qu'elles soient équipées ou non d'une carte réseau.
Si un système n'a pas de fonction de base pour générer des nombres alétoire de cryptage, alors il y a, la plupart du temps, un grand nombre de de possibilités pour trouver une séquence aléatoire permettant de générer une valeur. Les types de données sources listées ci-après dépendent bien sûr du système, mais très souvent on trouve :
(Remarquez que c'est précisément le type de ressources aléatoires mentionnées ci-dessus qui sont utilisées pour alimenter les générateurs de nombres alétoires de qualité cryptographique sur des systèmes dont le matériel n'est pas équipé de fonctions spécifiques pour les générer.)
De plus, des données tels que le nom de l'ordinateur et le nom du système d'exploiation, bien que ne pouvant être qualifiées d'alétoire à proprement parler, pourront aider à faire la diffférence avec les nombres aléatoires produits par d'autres systèmes.
L'algorithme exact de génération d'un identifiant de noeud utilisant ces données est spécifique au système, parce que les données disponibles et les fonctions pour les obtenir sont à la fois et souvent très spécifiques au système. Toutefois, en acceptant que l'on pourrait concaténer toutes les valeurs des sources aléatoires dans un buffer, et qu'une fonction de hachage cryptographique telle que MD5 soit disponible, alors tout mot de 6 octets du buffer de hachage de MD5, ayant le bit multicast initialisé (le bit de poids fort du premier octet) pourra être un identifiant de noeud alétoire acceptable.
D'autres fonctions de hachage, telle que par exemple SHA-1, peuvent aussi être utilisées. La seule obligation est que le résultat soit un nombre aléatoire adapté, c'est à dire qu'à un ensemble d'entrées uniformément distribué produise un ensemble de sorties elles-mêmes uniformément distribuées, et que la modification d'un seul bit en entrée provoque le changement de plus de la moitié des bits de sortie.
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 .
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 .
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 .
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.
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.
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.
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é.
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.
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.
IfSi 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.
>>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.
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.
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.
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.
PROPFINDLa 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.
>>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.
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 :
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 :
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 ).
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 :
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,
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:
".
PROPFIND La méthode PROPPATCH traite des instructions spécifiées
dans le corps de la requête pour assigner et/ou supprimer des propriétés
définies sur la ressource identifiée par l'URI requête.
Toutes les ressources conformes à DAV DOIVENT supporter la méthode
PROPPATCH et DOIVENT traiter des instructions qui sont spécifiées
par les éléments XML propertyupdate, set , et remove
du schéma de données de DAV. L'exécution des consignes
dans cette méthode est, bien sûr, soumise aux restrictions des
contrôles d'accès. Les ressources conformes à DAV DOIVENT
supporter l'initialisation de n'importe quelle propriété potentiellement
morte.
La corps du message de requête d'une méthode PROPPATCH
DOIT contenir l'élément XML propertyupdate
. Le traitement des instructions DOIT se faire dans l'ordre des instructions
reçues (c'est à dire de haut en bas). Les instructions DOIVENT
être soit toutes exécutées soit ne pas être exécutées
du tout. Ainsi, si une erreur survient pendant le traitement alors toutes les
instructions déjà exécutées DOIVENT être
annulées et un code d'erreur approprié doit être retourné.
Le traitement détaillé des instructions peut être trouvé
dans la définition des instructions set et remove
dans la section 12.13.
207Les 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é.
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 .
MKCOLLa méthode MKCOL est utilisée pour créer
une nouvelle collection. Toutes les ressources conformes à DAV DOIVENT
supporter la méthode MKCOL .
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.
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 :
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.
MKCOLCette 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
GET et HEAD
appliquées à des collectionsLa 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.
POST appliquée
à des collectionsPuisque 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.
DELETEDELETE appliquée
à des ressources autres que des collectionsSi 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.
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.
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.
PUTPUT pour des ressources
autres que des collectionsUn 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).
PUT appliquée
à des collectionsComme 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.
COPYLa 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.
COPY pour des ressources
HTTP/1.1Quand 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.
COPY appliquée
à des propriétésLa 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.
COPY appliquée
à des collectionsLa méthode COPY appliquée à une collection
sans avoir précisé la valeur de l'entête Depth
DOIT agir en prenant comme valeur par défaut "infinity".
Les valeurs qu'un client a le droit de soumettre dans l'entête depth
de la méthode COPY sont "0" ou "infinity".
Les serveurs conformes DAV DOIVENT supporter ces deux valeurs.
La valeur infinity signifie que la collection d'origine, identifiée
par l'URI requête, doit être copiée à l'emplacement
spécifié par l'URI fournie dans l'entête Destination,
et que toutes les ressources membres internes de la collection d'origine, sur
tous ses niveaux de profondeur, doivent être récursivement copiées
à l'emplacement de la ressource de destination.
Une COPY avec "Depth: 0" ne fait que signifier que
la collection d'origine et ses propriétés doivent être copiés
mais pas les ressources identifiées par ses URI de membres internes.
Toute entête spécifiée dans une requête COPY
DOIT être appliquée à chaque ressource copiée,
pendant sa copie, à l'exception de l'entête Destination.
L'entête Destination ne fait que spécifier l'URI
"de destination" de l'URI requête. Quand on l'applique aux membres
de la collection identifiée par l'URI requête, la valeur de Destination
est modifiée pour refléter la position relative des ressources
dans la hiérarchie copiée.
Ainsi : Soit la resource /a/ à laquelle on applique les
valeurs http://fun.com/ comme valeur
d'entête Host et http://fun.com/b/
pour valeur d'entête Destination, alors quand la ressource
http://fun.com/a/c/d est copiée,
la Destination qui DOIT être utilisée est
http://fun.com/b/c/d.
Quand l'exécution de la méthode COPY est terminée,
elle DOIT avoir créé au niveau de la destination un espace
de noms régulier (se référer à la section 5.1 pour
la définition des espaces de noms réguliers). Toutefois, si une
erreur se produit pendant la copie d'une collection interne, le serveur NE
DOIT copier aucune des ressources identifiées par les membres
de cette collection (en clair, par exemple, le serveur DOIT ignorer le
sous-arbre de cette collection), parce que cela reviendrait sinon à créer
un espace de noms irrégulier. Quand une erreur est ainsi détectée,
l'opération de COPY DEVRAIT essayer de se terminer
de manière à ce que le résultat soit le plus proche possible
de ce qu'était la ressource source à copier (par exemple, le serveur
doit essayer de copier les autres sous-arbres et leurs membres de la ressource
source, ceux qui ne sont pas des descendants de la collection ayant causé
le problème). Par exemple, si un COPY avec une profondeur
infinity est appliqué à la collection /a/,
contenant les collections /a/b/ et /a/c/, et qu'une
erreur intervient lors de la copie de /a/b/, alors la méthode
doit quand même essayer de copier /a/c/.
De la même manière, si une erreur arrive lors de la copie d'une
ressource qui n'est pas une collection et dans le cas d'un COPY
de type infinity, le serveur DEVRAIT essayer de terminer
le traitement en rendant un résultat qui soit le plus proche possible
du résultat souhaité. Si une erreur dans l'exécution de
la méthode COPY survient sur une ressource autre que celle
identifiée par l'URI requête alors la réponse DOIT
être le code 207 (multi-état).
Le code 424 (Echec de dépendance) NE DEVRAIT PAS
être retourné dans une réponse de type 207
(multi-état) résultant de l'exécution de la méthode
COPY. Les réponses peuvent être omises en toute sécurité
parce que le client sera informé que la progéniture d'une ressource
n'a pas pu être copiée quand il recevra l'erreur relatve aux parents.
De plus, les codes 201 (Créé) et 204
(Pas de contenu) NE DEVRAIT PAS être retournés dans
les réponses 207 (états multiples) produites par la méthode
COPY. Elles peuvent également être omises en toute
sécurité parce qu'il s'agit des codes par défaut en cas
de réussite.
COPY et entête
OverwriteSi 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.
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.
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
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
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.
MOVELe 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.
MOVE appliquée
aux propriétésLe 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.
MOVE appliquée
à des collectionsL'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.
MOVE et l'entête
OverwriteSi 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.
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.
MOVE d'une ressource
autre qu'une collectionCette 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
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.
LOCKLa 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.
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.
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.
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.
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.
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.
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é.
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.
>>Requête
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D='DAV:'>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
<D:owner>
<D:href>http://www.ics.uci.edu/~ejw/contact.html</d:href>
</D:owner>
</D:lockinfo>
>>Réponse
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>Infinity</D:depth>
<D:owner>
<D:href>http://www.ics.uci.edu/~ejw/contact.html
</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href>opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
Cet exemple montre la création réussie d'un verrou d'écriture
exclusif sur la ressource http://webdav.sb.aol.com/workspace/webdav/proposal.doc.
La ressource http://www.ics.uci.edu/~ejw/contact.html
contient les données d'identification du propriétaire du verrou.
Le serveur a une politique de gestion du temps limite basée sur l'activité
de cette ressource, et entraîne la destruction automatique du verrou après
une semaine (604800 secondes). Remarquez que les champs nonce,
response, et opaque n'ont pas été calculés
dans l'entête Authorization de la requête.
>>Requête
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000
If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>) Authorization:
Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
>>Réponse
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>Infinity</D:depth>
<D:owner>
<D:href>http://www.ics.uci.edu/~ejw/contact.html
</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href>opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
Cette demande rafraîchirait le verrou en réinitialisant tous les
compteurs de limitation de temps. Remarquez que le client a demandé un
temps infini mais que le serveur a choisi d'ignorer cette demande. Dans cet
exemple, les champs nonce, response, et opaque
n'ont pas été calculés dans l'entête Authorization
de la requête.
>>Requête
LOCK /webdav/ HTTP/1.1
Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000
Depth: infinity
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D="DAV:">
<D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope>
<D:owner>
<D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
</D:owner>
</D:lockinfo>
>>Réponse
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://webdav.sb.aol.com/webdav/secret</D:href>
<D:status>HTTP/1.1
403 Forbidden</D:status>
</D:response>
<D:response>
<D:href>http://webdav.sb.aol.com/webdav/</D:href>
<D:propstat>
<D:prop><D:lockdiscovery/></D:prop>
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:propstat>
</D:response>
</D:multistatus>
Cet exemple montre une demande de pose d'un verrou d'écriture exclusif sur une collection et tout ses enfants. Dans cette requête, le client a spécifié qu'il souhaite obtenir un verrou de durée infinie, si un tel verrou est disponible, et, dans le cas contraire, souhaite obtenir un temps limité à 4.1 millliards de secondes, si cela est possible. Le corps de l'entité requête contient l'information d'identification du demandeur faisant la demande de verouillage, ici, il s'agit de l'URL d'une page web.
La réponse retournée concernant la ressource http://webdav.sb.aol.com/webdav/secret
est 403 (Interdit). Et comme cette ressource ne put être
verrouillée, aucune autre ne le fut. Remarquez aussi que la propriété
lockdiscovery de l'URI requête a été incluse
dans la réponse comme cela est exigé. Dans cet exemple, la propriété
lockdiscovery est vide, ce qui signifie qu'il n'y a actuellement
aucun verrou de posé sur cette ressource.
Dans cet exemple, les champs nonce, response, et
opaque n'ont pas été calculés dans l'entête
Authorization de la requête.
UNLOCKLa 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.
UNLOCK>>Requête
UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: webdav.sb.aol.com
Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7> Authorization:
Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc",
response="...", opaque="..."
>>Réponse
HTTP/1.1 204 No Content
Dans cet exemple, le verrou identifié par le marqueur de verrou "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7"
est retiré avec succès de la ressource http://webdav.sb.aol.com/workspace/webdav/info.doc.
Si ce verrou avait inclu plus d'une ressource, le verrou aurait été
supprimé sur chacune d'elles. Le code d'état 204
(Pas de contenu) est utilisé au lieu du code 200 (OK) parce
que l'entité réponse n'a pas de corps.
Dans cet exemple, les champs nonce, response, et
opaque n'ont pas été calculés dans l'entête
Authorization de la requête.
HTTP pour la rédaction
distribuéeDAVDAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
Cet entête indique que la ressource supporte le schéma et le protocole
DAV tels que spécifiés. Toute ressource conforme à
DAV DOIT retourner l'entêtes DAV avec
toute réponse à la méthode OPTIONS.
La valeur est une liste de toutes les classes conformes que la ressource supporte.
Remarquez que ci-dessus, une virgule a déjà été
rajoutée au 2. C'est parce qu'une ressource ne peut pas
avoir une conformité de niveau 2 sans être également
conforme de niveau 1. Référez-vous à la section
15 pour plus de détails. En général, toutefois, le support
d'une classe de conformité ne présage pas du support d'aucune
autre.
DepthDepth = "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.
DestinationDestination = "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].
IfIf = "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].
No-tag-listLa 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.
IF avec
un No-tag-listIf: (<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"])).
Tagged-listLa 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.
If avec
Tagged-ListCOPY /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.
notChaque 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.
MatchingQuand 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.
If et les proxies
non conformes à DAVLes proxies qui ne sont pas conformes à DAV ne sauront pas traiter l'entête
If et HTTP impose que les entêtes incomprises soient ignorées.
Donc, quand on communique avec des proxies par le protocole HTTP/1.1, l'entête
de requête "Cache-Control: no-cache" DOIT être
utilisée afin d'empêcher que le proxy essaie, mal, de satisfaire
la requête en utilisant sa mémoire cache. Avec les proxies HTTP/1.0
l'entête de requête "Pragma: no-cache" DOIT
être utilisée pour les mêmes raisons.
Lock-TokenLock-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éé.
OverwriteOverwrite = "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.
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.
TimeoutTimeOut = "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other) DAVTimeOutVal = 1*digit
Other = "Extend" field-value ; Voir la section
4.2 of [RFC2068]
Les clients peuvent inclure les entêtes Timeout dans leurs
requêtes LOCK. Toutefois, le serveur n'est pas obligé
d'honorer voir même seulement de considérer ces entêtes.
Les entêtes Timeout sont réservées aux requêtes
portant sur la méthode LOCK : les clients NE DOIVENT
PAS soumettre d'entête Timeout avec toute méthode
autre que la méthode LOCK.
L'entête Timeout DOIT contenir au moins un TimeType
et peut en contenir plusieurs. L'objectif d'une liste de TimeType
est de pouvoir indiquer au client plusieurs valeurs et types de valeurs qui
lui soient acceptables. Le client liste les entrées TimeType
par ordre de préférence.
Les valeurs de la réponse à un Timeout DOIVENT
utiliser l'une des valeurs Second, Infinite, ou un
TimeType que le client a déclaré comme lui étant
familier. Le serveur est en droit de supposer que le client est familier avec
n'importe lequel des TimeType qui lui a été soumis
dans l'entête Timeout.
Le TimeType "Second" spécifie le nombre
de secondes qui s'écouleront entre le moment ou le verrou sera accordé
par le serveur et la destruction automatique de ce verrou. La valeur de limite
de temps pour le TimeType "Second" NE DOIT
PAS être plus grand que 232-1.
Le compteur de limite de temps DEVRAIT être réinitialisé
à chaque fois que le propriétaire d'un verrou envoie une méthode
à n'importe lequel des membres du verrou, y compris des méthodes
non-supportées, ou des méthodes qui ont échouées.
Toutefois, le verrou DOIT être rafraîchi si la méthode
de rafraîchissement de LOCK est reçue avec succès.
Si la limite de temps est atteinte, alors le verrou peut être perdu.
Plus précisément, si le serveur souhaite récupérer
les verrous en dépassement de temps, il DOIT agir comme si il
exécutait une méthode UNLOCK sur la resource utilisant
le marqueur du verrou en dépassement de temps. Cela pourrait être
fait au titre des privilèges que lui confère son autorité
en écrasement. Des traces de cette activité devraient alors être
mises à jour et indiquer l'emplacement des verrous, envoyer des notifications
etc..., exactement comme cela se fait pour les requêtes de la méthode
UNLOCK.
Les serveurs sont avertis qu'ils doivent prêter une attention toute particulière aux valeurs qui leurs sont soumises par les clients, puisqu'elles seront autant d'indications quant au type d'activité que le client a l'intention d'exécuter. Par exemple, une applet s'exécutant dans un navigateur peut avoir besoin de verrouiller une ressource ; mais à cause de l'instabilité de l'environnement dans lequel elle s'exécute, elle peut très bien être arrêtée sans qu'aucun message d'avertissement soit émis. En conséquence, il est fortement probable que l'applet aura besoin d'avoir un temps limite d'exécution de petite durée de manière à ce que, si elle venait à mourir, le verrou pourrait être rapidement récupéré. Toutefois, un système de gestion de documents a de fortes chances d'avoir besoin de demander des durées de temps limite extrêmement longues parce que son utilisateur peut plannifier de continuer son travail rédactionnel hors connexion.
Un client NE DOIT PAS se contenter de considérer qu'un verrou est perdu parce que le temps limite prévu a été dépassé.
Les codes d'états suivants ont été ajoutés à ceux définis dans HTTP/1.1 [RFC2068].
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.
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).
422 : entité
impossible à traiterLe 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.
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.
424 : échec
de dépendanceLe 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).
507 : mémoire
insuffisanteLe 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.
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.
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).
activelockNom : 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?) >
depthNom : depth
Espace de noms : DAV:
Objet : La valeur de l'entête Depth.
Valeur : "0" | "1" | "infinity"
Modèle de contenu : <!ELEMENT depth (#PCDATA) >
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+) >
timeoutNom : 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) >
collectionNom : 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 >
hrefNom : 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)>
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+) >
dstNom : dst
Espace de noms : DAV:
Objet : Indique la destination d'un lien
Valeur : URI
Modèle de contenu : <!ELEMENT dst (#PCDATA) >
srcNom : src
Espace de noms : DAV:
Objet : Indique la source d'un lien.
Valeur : URI
Modèle de contenu : <!ELEMENT src (#PCDATA) >
lockentryNom : 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)
>
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?) >
lockscopeNom : 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) >
exclusive Nom : exclusive
Espace de noms : DAV:
Objet : Spécifie un verrou exclusif
Modèle de contenu : <!ELEMENT exclusive EMPTY >
sharedNom : shared
Espace de noms : DAV:
Objet : Spécifie un verrou partagé
Modèle de contenu : <!ELEMENT shared EMPTY >
locktypeNom : 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) >
writeNom : write
Espace de noms : DAV:
Objet : Spécifie un verrou d'écriture.
Modèle de contenu : <!ELEMENT write EMPTY >
multistatusNom : 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?) >
responseNom : 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?) >
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?) >
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) >
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)
>
ownerNom : 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>
propNom : 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>
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) >
keepaliveNom : 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+)
>
omitNom : 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 >
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)+ >
removeNom : 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) >
setNom : 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) >
propfindNom : 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) >
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 >
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 >
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).
creationdateNom : 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)
>
displaynameNom : 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) >
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)
>
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)
>
getcontenttypeNom : 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)
>
getetagNom : 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) >
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)
>
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)*
>
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.
resourcetypeNom : 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 >
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)* >
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.
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)*
>
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>
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.
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é.
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.
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.
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.
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.
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.
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.
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.
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é.
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.
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.
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.
Cette spécification, dans sa section 6.4, exige l'utilisation des Identifiants
Uniques Universel (Universal Unique Identifiers -UUID-) pour les marqueurs de
verrous, afin de garantir leur unicité dans le temps et l'espace. Les
UUIDs, tels que définis dans [ISO- 11578], contiennent un champ "node"
qui "consiste en l'adresse IEEE, qui, d'habitude, est celle de l'ordinateur.
Pour les systèmes qui ont plusieurs noeuds IEEE 802, toute adresse disponible
de noeud peut être utilisée." Puisqu'un serveur WebDav produira
beaucoup de verrous au cours de sa vie, la conséquence est qu'il va aussi
publiquement exposer ses addresses IEEE 802.
Il y a plusieurs risques consécutifs à l'exposition d'adresses IEEE 802. En utilisant les adresses IEEE 802 :
Dans la section 6.4.1 de cette spécification, on y détaille un
mécanisme altérnatif pour générer le champs "node"
d'une UUID sans utiliser une adresse IEEE 802, ce qui allège les risques
associés à l'exposition des adresses IEEE 802 par utilisant d'une
source alternative d'unicité.
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
"" pour la propriété
"DAV:creationdatecreationdate".
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.
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.
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.
[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-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/
[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.
[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.
[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
[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.
[USMARC] Network Development and MARC Standards, Office, ed. 1994.
"USMARC Format for Bibliographic Data", 1994. Washington, DC: Cataloging Distribution
Service, Library of Congress.
[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.
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: yarong@microsoft.com
Dept. Of Information and Computer Science
University of California, Irvine
Irvine, CA 92697-3425
EMail: ejw@ics.uci.edu
Netscape
685 East Middlefield Road
Mountain View, CA 94043
EMail: asad@netscape.com
Novell
1555 N. Technology Way
M/S ORM F111
Orem, UT 84097-2399
EMail: srcarter@novell.com
Novell
1555 N. Technology Way
M/S ORM F111
Orem, UT 84097-2399
EMail: dcjensen@novell.com
Cette section fournit une Définition de Type de Documents, correspondant aux règles de [REC-XML], pour les éléments XML utilisés dans le flot du protocole et dans les valeurs des propriétés. Elle rassemble les définitions d'éléments données aux sections 12 et 13.
<!DOCTYPE webdav-1.0 [ <!--============ XML Elements
from Section 12 ==================-->
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
locktoken?) >
<!ELEMENT lockentry (lockscope, locktype) >
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
<!ELEMENT locktype (write) >
<!ELEMENT write EMPTY >
<!ELEMENT lockscope (exclusive | shared) >
<!ELEMENT exclusive EMPTY >
<!ELEMENT shared EMPTY >
<!ELEMENT depth (#PCDATA) >
<!ELEMENT owner ANY >
<!ELEMENT timeout (#PCDATA) >
<!ELEMENT locktoken (href+) >
<!ELEMENT href (#PCDATA) >
<!ELEMENT link (src+, dst+) >
<!ELEMENT dst (#PCDATA) >
<!ELEMENT src (#PCDATA) >
<!ELEMENT multistatus (response+, responsedescription?) >
<!ELEMENT response (href, ((href*, status)|(propstat+)), responsedescription?)
>
<!ELEMENT status (#PCDATA) >
<!ELEMENT propstat (prop, status, responsedescription?) >
<!ELEMENT responsedescription (#PCDATA) >
<!ELEMENT prop ANY >
<!ELEMENT propertybehavior (omit | keepalive) >
<!ELEMENT omit EMPTY >
<!ELEMENT keepalive (#PCDATA | href+) >
<!ELEMENT propertyupdate (remove | set)+ >
<!ELEMENT remove (prop) >
<!ELEMENT set (prop) >
<!ELEMENT propfind (allprop | propname | prop) >
<!ELEMENT allprop EMPTY >
<!ELEMENT propname EMPTY >
<!ELEMENT collection EMPTY > <!--=========== Property Elements
from Section 13 ===============-->
<!ELEMENT creationdate (#PCDATA) >
<!ELEMENT displayname (#PCDATA) >
<!ELEMENT getcontentlanguage (#PCDATA) >
<!ELEMENT getcontentlength (#PCDATA) >
<!ELEMENT getcontenttype (#PCDATA) >
<!ELEMENT getetag (#PCDATA) >
<!ELEMENT getlastmodified (#PCDATA) >
<!ELEMENT lockdiscovery (activelock)* >
<!ELEMENT resourcetype ANY >
<!ELEMENT source (link)* >
<!ELEMENT supportedlock (lockentry)* > ]>
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.
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.
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.
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.
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é.
Tout système conforme à DAV DOIT supporter les extensions d'espaces de noms XML en conformité avec la spécification [REC-XML-NAMES].
[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.
Copyright (C) The Internet Society (1999). Tous droits réservés.
Ce document et ses traductions peuvent être copiés et transmis à d'autres personnes, et des travaux dérivés afin de le commenter ou lui rajouter des explications ou aider à son implémentation peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d'une quleconque nature, à condition que la mention de copyright ci-dessus et ce paragraphe soient inclus sur toutes ces copies et travaux dérivés. Toutefois, ce document lui-même ne peut pas être modifié d'aucune façon, comme par exemple en retirant le copyright ou les références à "the Internet Society" ou d'autres organisaitons Internet, excepté quand cela est justifié pour le développement des standards Internet auquel cas les procédures concernant les copyrights définies dans les processus de production des standards Internet (the Internet Standards process) DOIVENT être respectés, ou comme cela est requis de les traduire en d'autres langages que l'anglais.
La permission limitée qui est accordée ci-dessus sont perpétuelles et ne seront pas révoquées par "the Internet Society" ou ses successeurs ou ses assignés.
Ce dcoument et l'information qu'il contient ci-dessus est fourni sur une base "TEL QUEL" et "THE INTERNET SOCIETY" ET "THE INTERNET ENGINEERING TASK FORCE" SE DESENGAGENT DE TOUTE GARANTIE, EXPRES OU IMPLICITE, INCLUANT SANS TOUTEFOIS ETRE LIMITEE A TOUTE GARANTIE QUE L'UTILISATION DE L'INFORMATION CI-DESSUS N'ENFREINDRA PAS DES DROITS OU TOUTE GARANTIE CONSECUTIVE DE TYPE COMMERCIALE OU D'ADEQUATION POUR UN USAGE PARTICULIER QUEL QU'IL SOIT.