Manuele Kirsch Pinheiro
(Manuele.Kirsch_Pinheiro@inrialpes.fr)
Le protocole WebDAV est une extension du protocole HTTP/1.1 qui définit des nouvelles méthodes pour la rédaction éloignée sur le Web. Il s'agit d'une infrastructure standard pour la rédaction en collaboration asynchrone sur l'Internet. Il définit des nouvelles méthodes, headers, request entity body format et reponse entity body format pour des opérations sur des propriétés, collections, namespace et overwriting protection. [RFC 99], [WHITEHEAD 98], [DRIDI 99]
Dans sa première proposition, le WebDAV a aussi inclu l'idée du travailler sur le contrôle d'accès et la gestion de versions, mais ces deux fonctions ont été déplacées vers un sous-groupe du travail du WebDAV et pour le groupe de travail IETF Delta-V, respectivement. Le groupe Delta-V objective faire une extension des protocoles WebDAV et HTTP/1.1 avec des gestion des versions [WHITEHEAD 99].
La spécification du protocole WebDAV définit sept nouvelles méthodes : PROPFIND et PROPPATH pour la gestion des propriétés, LOCK et UNLOCK pour le verrouillage des ressources, COPY et MOVE pour la gestion de namespace, et MKCOL pour la création des collections. En additions à ces méthodes, la spécification WebDAV définit aussi des modifications dans le comportement des méthodes DELETE et PUT du HTTP/1.1, à fin qu'ils puissent traiter les propriétés et les collections.
Encore un autre modification du WebDAV sur HTTP est sur les réquisitions. Au contraire du protocole HTTP/1.1, qui n'utilise que des headers HTTP, le WebDAV utilise des headers HTTP, et aussi des paramètres des méthodes et un request entity body en XML, et toutes ses réponses sont codés en XML. D'ailleurs, le protocole WebDAV définit le comportement des méthodes DELETE et PUT pour les propriétés et les collections, et aussi il définit des nouveaux codes pour les réponses (status codes). [RFC 99]
Quelques détails sur chacune des ses opérations définis par le protocole WebDAV sont présentés au-dessous.
Les propriétés sont des morceaux d'information qui décrivent l'état d'une ressource. Elle sont des meta-donnés formés par la paire nom /valeur. Le nom est un URI qui fait référence à la syntaxe et à la sémantique de la propriété, et la valeur est un code XML bien formé (well-formed) . Il y a deux types de propriétés : les "vivantes" (live) et les "mortes" (dead). Les premières sont des propriétés qui ont leur syntaxe et leur sémantique définie par le serveur (c'est le cas des propriétés où le serveur fait le soutien ou la vérification des valeurs). Les dernières (dead properties) ont leur syntaxe et sémantique définie par le client, le serveur seulement garde leurs valeurs. [RFC 99], [DRIDI 99]
Il y a deux méthodes pour la manipulation des propriétés, quoi que soit leur type : PROPFIND et PROPPATH. La première méthode demande au serveur les propriétés définies d'une ressource, identifiée par le header Request-URI. Le client peut demander, dans le request entity body, quelques propriétés en particulier (à travers des éléments XML prop), toutes les propriétés de la ressource (élément XML allprop) ou une liste avec tous les noms des propriétés de la ressource (élément propname). Enfin, une demande sur une ressource du type collection est une demande pour les propriétés de tous ces membres. [RFC 99]
La méthode PROPPATH est similaire à la méthode PROPFIND, sauf qu'il s'agit d'un méthode pour définir ou effacer des propriétés. [RFC 99]
Les collections sont un nouveau type de ressource Web, dont l'état est, au minimum, d'une liste de URIs membres internes et d'un ensemble des propriétés. Une collection est comme un répertoire, où il est possible de mettre d'autres ressources (les membres internes). Ces membres doivent être immédiatement relatifs à l'URI base de la collection. Par exemple, si les ressources "http://foo.com/bar/blah" et http://foo.com/bar/" sont des ressources DAV (WebDAV compilant), la dernière doit être une collection et la première, un de ses membres. [RFC 99], [WHITEHEAD 98], [DRIDI 99]
Le protocole WebDAV définit la nouvelle méthode MKCOL pour créer une nouvelle collection dans le URI spécifié dans le header Request-URI. Cet URI ne peut pas exister avant l'appel du méthode, mais tous ces ancêtres doivent exister avant, autrement la méthode ira échouer [RFC 99].
Le protocole WebDAV fournit des méthodes pour que les utilisateurs puissent gérer le namespace dans le serveur Web qu'ils utilisent. Avec ce deux nouvelles méthodes (COPY et MOVE), plus la méthode DELETE, le client peuvent demander au serveur de copier, déplacer ou effacer des ressources Web. [WHITEHEAD 98], [DRIDI 99]
La méthode COPY crée un duplicata de la ressource source, identifiée par le header Request-URI, dans la ressource destination, indiquée par le header Destination. Le serveur essaye de faire la meilleure copie de la ressource source et ces propriétés (toutes les propriétés ou seulement une liste d'elles, selon l'élément XML propertybehavior) sur la ressource destination. Par exemple, s'il échoue la copie d'une propriété "vivante" (live), il doit faire un duplicata de cette propriété dans une propriété "morte" (dead). Cette méthode peut aussi faire la copie des collections elles-mêmes (avec ses propriétés), ou de tous ses membres internes et ses propriétés, récursivement par toute sa hiérarchie, selon le header Depth. Le résultat de la méthode COPY doit être un namespace consistent dans la destination. [RFC 99]
La méthode MOVE est similaire à la méthode COPY, mais il déplace la ressource source vers l'URI destination (identifié par le header Destination). Son opération est équivalente à une opération de COPY suivie par un processus de soutien de la consistance chez le serveur (il fait des actualisations causées par le mouvement) et par la suppression de la ressource source. Sur les collections, la méthode MOVE doit déplacer tous les membres internes et toute leur hiérarchie (le header Depth doit absolument être "infinity"). Le résultat doit être un namespace consistant dans la source et la destination. Si une erreur se produit pendant la méthode MOVE, ainsi que pendant la méthode COPY, le serveur ne doit pas déplacer les éléments de la hiérarchie où l'erreur a été produite, mais il doit essayer de déplacer le maximum de la ressource source possible. [RFC 99]
Les opérations pour le verrouillage des ressources proposées par le protocole WebDAV sont destinées à prévention de overwriting des ressources, cet à dire, la prévention du problème de la mise à jour perdue. Le protocole fournit, à travers de deux méthodes, un mécanisme pour mettre en série les accès à une ressource. [RFC 99], [WHITEHEAD 98], [DRIDI 99]
Le protocole WebDAV définit que les verrous peuvent être exclusif (exclusive lock) ou partagé (shared lock). Le premier garantit que seulement une personne aura le droit d'accès, et il exclut ce droit des autres auteurs. Le deuxième permet que plusieurs personnes reçoivent le verrou et obtiennent le droit d'accès. Donc, un groupe d'auteurs peut travailler ensemble sur le document, mais ils doivent se faire confiance les uns et les autres. D'ailleurs, le protocole ne définit qu'un seul type de verrou pour le droit d'écriture sur une ressource (write lock). Ce verrou prévient que quelqu'un sans le verrou exécute les opérations PUT, POST, PROPPATH, LOCK, UNLOCK, MOVE, DELETE et MKCOL sur les ressources verrous. S'il s'agit d'un verrou sur une collection, il préviendra aussi l'addition et la suppression des ressources membres pour des personnes qui ne possèdent pas le verrou. Et une autre caractéristique importante des verrous dans le protocole WebDAV est que le verrou est assigné pour une personne, et pas pour un logiciel. [RFC 99], [WHITEHEAD 98]
Un verrou possède un temps d'expiration (timeout), et un client ne doit jamais soumettre le même verrou deux fois. Par contre, il peut soumettre une réquisition (méthode LOCK avec le header If et sans un body) pour le rafraîchissement du verrou. Le serveur doit, dans la première demande du verrou, retourner le temps d'expiration dans le header Timeout, et il peut aussi, dans une demande de rafraîchissement, retourner ce même header. En addition, le client peut soumettre une valeur pour le temps d'expiration dans le header Timeout de la réquisition, mais le serveur peut aussi ignorer cette valeur. Néanmoins, tous les clients doivent assumer que ses verrous peuvent disparaître à n'importe quand, quoique soit la valeur du temps d'expiration. Le temps qui le serveur retours dans le header Timeout indique le comportement du serveur si aucune situation extraordinaire arrive. [RFC 99]
Le protocole WebDAV propose deux nouvelle méthodes sur les verrous, la méthode LOCK et la méthode UNLOCK, tous les deux applicable à quelque type de verrou. Le première crée ou rafraîchisse un verrou sur le ressource identifié par le Request-URI. Autres informations sont soumis dans le body de la réquisition. C'est le cas de l'élément XML lockinfo,lequel indique si le verrou est exclusif ou partagé (sous-élément lockscope), et quel est son type (sous-élément locktype). C'est aussi le cas de l'élément owner (facultatif dans le rafraîchissement d'un verrou), qui indique le propriétaire du verrou, et le cas de l'élément timeout, pour le temps d'expiration dans l'élément. [RFC 99]
La méthode LOCK est applicable sur la ressource, et pas sur son URI. Donc, si le serveur n'est pas capable d'assurer le verrou par tous les URI qui donnent accès à la ressource, la réquisition LOCK doit échouer. Le même est valable pour les collections. En addition, dans une réquisition de LOCK pour une collection, le client peut indiquer s'il voudrait verrouiller seulement la collection et ses propriétés ou s'il voudrait verrouiller toutes les ressources internes de la collection. Il peut indiquer sa volonté par le header Depth, avec les valeurs "0" ou "infinity", respectivement. [RFC 99]
La méthode UNLOCK supprime le verrou identifié par le header Lock-Token. Cette valeur est une identification unique qui est retourné dans chaque appel réussite de la méthode LOCK (alors, un verrou partagé peut avoir plusieurs Lock-Tokens, un for chaque auteur qui possède le verrou). La méthode UNLOCK instruit le serveur à effacer le verrou sur la ressource indiquée (Request-URI) et sur toutes les ressources incluses dans le verrou. Si toutes ces ressources incluses ne peuvent pas être libérées, la méthode UNLOCK doit échouer. [RFC 99]
En dehors de ces deux méthodes, un client DAV peut aussi demander au serveur s'il supporte des verrous et quels types à travers la propriété supportedlock . Cette caractéristique du protocole WebDAV, laquelle s'appelle "lock capability discovery", est très importante, car le protocole définit qu'un serveur n'est pas obligé de supporter des verrous. Le client peut aussi découvrir, en utilisant la propriété lockdiscovery, quelles sont les ressources verrouillées et qui les possède (active lock discovery). [RFC 99]
Finalement, il faut remarquer que le protocole n'est pas une garantie que le problème de mise à jour perdue n'ira jamais se produire. Il faut considérer, par exemple, un client A, qui ne supporte pas le protocole WebDAV (un client HTTP seulement), et client B, qui supporte le protocole WebDAV. Le client A peut faire un GET dans une ressource et la changer. Pendant cette période, le client B peut faire un LOCK, suivi par un GET, et aussi change la ressource. Le client B peut terminer ses modifications avant le client A, et il fera un PUT suivi par un UNLOCK. Après tous ça, le client A fera un PUT, un déposant sa nouvelle version du ressource, et les modifications réalisées par le client B seront perdues (voici la Figure 1 au-dessus). Ce problème se produit parce que le protocole WebDAV est compatible avec des clients HTTP qui ne le comprennent pas et aussi avec des clients et des serveurs qui n'utilisent pas des verrous. Le protocole ne peut pas aussi forcer la séquence LOCK/GET/PUT/UNLOCK, laquelle peut prévenir la mise à jour perdue. [RFC 99]
Les activités prévue pour l'implémentation du protocole WebDAV sur l'éditeur Amaya sont les suivantes :
étude des caractéristiques et de la structure de l'application Amaya
étude du protocole WebDAV.
identification des point dans l'application où il faudrait la changer pour introduire le support du protocole WebDAV.
définition de la structure du module qui ira implémenter le protocole WebDAV dans l'application.
implémentation et tests sur l'interface du module DAV avec l'application;
implémentation et tests des modifications réalisé dans l'application et dans l'interface utilisateur;
implémentations et tests des méthodes DAV pour la protection contre la "mise à jour perdue" (LOCK/UNLOCK);
implémentations et tests des méthodes DAV pour la manipulation des propriétés (PROPFIND/PROPPATH);
implémentation et tests des méthodes DAV pour copier et mouvoir des ressources Web (COPY/MOVE);
implémentation et tests des méthodes DAV pour la manipulations des collections (MKCOL).
tests sur l'intégration de chaque partie du module DAV à l'application et au propre module.
Ces activités doivent suivre le calendrier suivante :
| Novembre | Décembre | Janvier | Février | Mars | Avril | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 |
x |
|
|
|
|
|
|
|
|
|
|
|
2 |
x |
x |
|
|
|
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
|
|
|
|
|
|
4 |
|
|
|
|
|
|
|
|
|
|
|
|
5 5.1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.2 |
|
|
|
|
|
|
|
|
|
|
|
|
5.3 |
|
|
|
|
|
|
|
|
|
|
|
|
5.4 |
|
|
|
|
|
|
|
|
|
|
|
|
5.5 |
|
|
|
|
|
|
|
|
|
|
|
|
5.6 |
|
|
|
|
|
|
|
|
|
|
|
|
6 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Activités prévues |
|---|---|
x |
Activités déjà réalisées |
Pour l'implémentation du protocole WebDAV dans l'éditeur Amaya, il faut considérer plusieurs aspects. Le premier aspect est le support aux serveurs non-WebDAV. L'application Amaya doit rester compatible avec des serveurs DAV et des serveurs HTTP ordinaires qui ne comprennent pas l'idée d'un verrou. D'ailleurs, l'éditeur Amaya doit correspondre aux besoins d'un seul individu et aussi d'un groupe qui veut travailler ensemble. Pour un seul individu qui édite seul ses pages Web, le support au protocole HTTP est suffisant, mais quand un groupe de coauteurs travail sur plusieurs pages Web, il lui faudrait un support DAV, pour prévenir le problème de mise à jour. Par fin, il faut ne pas oublier qu'un même auteur peut travailler en groupe sur un ensemble de ressources et aussi travailler seule sur d'autres.
À cause de ces considérations, on propose une implémentation qui activement demande au utilisateur s'il veut ou non utiliser les méthodes du protocole WebDAV. Cette implémentation pourra être réaliser à travers d'une interface avec l'utilisateur que lui demande activement quel opération DAV il veut exécuter sur le ressource. Ceci peut être réaliser par élément de interface, comme des menus ou par des palettes,à exemple des palettes SVG et MathML. L'utilisateur pourra, donc, interagir avec cet élément et cette interaction ira déclencher la(es) méthode(s) DAV correspondants, laquelle (lesquelles) ira construire la réquisition et la envoyer pour le serveur (voici la Figure 2 au-dessous).
Cette proposition est moins transparente que l'implémentation actuelle du Amaya, où l'utilisateur travaille avec le protocole HTTP d'une façon tout à fait transparente. Par contre, cette implémentation permet aux utilisateurs de travailler sur des ressources privées ou sur des ressources coopératives, selon sa volonté. Si l'utilisateur ne veut pas, ou il ne peut pas, travailler avec des serveurs WebDAV, il le pourra sans aucun problème. L'utilisateur pourra choisir entre les ressources DAV ou HTTP pendant son travail, selon ses besoins.
Dans le cadre du projet CEMT (CNPq-INRIA), cette structure fournit d'autres avantages, car elle permet l'introduction rapide des éléments de vérification entre l'interaction de l'utilisateur et l'activation de la méthode DAV. Par exemple, quand un utilisateur demande un verrou exclusif sur document, l'application pourra vérifier si le workflow permet ce verrou.
En dehors des calendrier présenté dans la section 2, il y a d'autres activités liées au projet CEMT qui touchent l'application Amaya. Ces activités sont programmées par les mois de octobre/01 et mai/02. Les activités qui doivent être réalisées au sein du Projet Opéra sont les suivantes :
création d'une DTD pour exprimer un workflow, dirigé au domaine de e-learning;
amélioration du protocole de awareness utilisé, transformation de la syntaxe de ce protocole en une syntaxe XML;
amélioration du prototype AmayaBW (l'application Amaya avec un support à awareness pour le travail en groupe);
intégration des fonctions du workfow (consultation).
[DRIDI 99] DRIDI, F.; GUSTAV, N. How to implement Web-based Groupware Systems based on WebDAV. In. IEEE 8th Intl. Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises. Proceedings. Stanford, CA, June 16-18, 1999. Disponible en <http://nestroy.wi-inf.uni-essen.de/Forschung/Publikationen/WETICE99/webdav-client-impl> (sept., 2001).
[RFC 99] GOLAND, Y.; WHITEHEAD, E.; FAIZI, A.; JENSEN, D.; HTTP Extensions for Distributed Authoring - WebDAV. RFC 2518. IETF, fev. 99. Disponible en < http://andrew2.andrew.cmu.edu/rfc/rfc2518.html > (sept., 2001).
[WHITEHEAD 98] WHITEHEAD, E.; WIGGING, M. WebDAV : IETF Standard for Collaborative Authoring on the Web. IEEE Internet Computing. IETF, sep-oct/98. Disponible en <http://www.ics.uci.edu/pub/ietf/webdav/intro/webdav_intro.pdf > (sept., 2001).
[WHITEHEAD 99] WHITEHEAD, E. J. The future of Distributed Software Development on the Internet. Web Techniques, n°. 10, 1999. Disponible en <http://www.webtechniques.com/archives/1999/10/whitehead/ > (sept., 2001).