Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)

Date de publication du RFC : Juin 2007
Auteur(s) du RFC : L. Dusseault (Commerce.net)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF webdav
Première rédaction de cet article le 2 juillet 2007


Ce RFC spécifie une nouvelle version du protocole WebDAV (Web Distributed Authoring and Versioning), initialement décrit dans le RFC 2518. Les changements sont peu nombreux.

WebDAV étend le protocole HTTP pour faciliter le travail en groupe sur les ressources distribuées via le Web. HTTP offrait déjà des moyens de modifier une ressource (une ressource est en général un document) par les commandes PUT et DELETE, en plus des commandes permettant d'y accéder (GET), mais elles étaient peu utilisées en dehors de certaines applications REST. WebDAV étend les possibilités de ces commandes, notamment par le concept de collection (un groupe de ressources) et par celui de versions, décrit dans le RFC 3253, dit Delta-V. En outre, il ajoute des nouvelles commandes comme :

  • PROPFIND pour récupérer la liste des propriétés (métadonnées) d'une ressource,
  • LOCK et UNLOCK pour mettre et retirer des verrous sur les ressources, afin d'éviter qu'un auteur ne marche sur les pieds d'un autre.

Les réponses à ces nouvelles commandes sont formulées en XML et, comme dans la plupart des RFC récents, notre RFC recommande dans l'appendice A.2 d'être très prudent avec le traditionnel principe Be liberal in what you accept and conservative in what you send, principe qui, sur le Web, a fait plus de mal que de bien.

WebDAV est un protocole complexe (notre RFC est plutôt gros et il faut déjà connaitre HTTP pour le lire) et qui n'est qu'un succès mitigé. En pratique, il semble que la plupart des gens qui maintiennent un site Web chargent leur fichier en FTP ou bien directement en TTW, Through The Web, c'est-à-dire via leur navigateur et un formulaire, comme on peut le faire avec la plupart des CMS.

L'un des utilisateurs le plus connus de WebDAV est Subversion dont c'est le principal protocole d'accès au dépôt. Un serveur Subversion est donc un serveur WebDAV étendu (car WebDAV ne suffisait pas, tout gros qu'il soit), en général un Apache avec les modules dav et dav_svn. Voici par exemple une configuration typique d'Apache pour Subversion :


LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so
LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so

<VirtualHost *:443>
        ServerAdmin webmaster@example.net
        ServerName svn.example.net

        SSLEngine on 
        SSLCertificateFile /etc/apache2/apache.pem

        <Location />
              DAV svn
             
              SVNPath /home/Subversion-Repository

             AuthType Basic
             AuthName "Subversion Repository"
             require valid-user
        </Location>

</VirtualHost>

On voit alors dans le journal du serveur les requêtes spécifiques à WebDAV, ici un PROPFIND lors d'un svn update :

192.0.2.69 - bortzmeyer [29/Mar/2007:12:05:35 +0200] "PROPFIND / HTTP/1.1" 207 629 "-" "SVN/1.4.2 (r22196) neon/0.26.2" 0 svn.example.net

Et ici la séquence d'ajout d'un nouveau fichier (par svn commit) qui se fait en déposant un fichier temporaire avec PUT, puis en le déplaçant avec MERGE - commande qui vient du RFC 3253 - avant de détruire le fichier temporaire avec DELETE :

192.0.2.69 - bortzmeyer [29/Mar/2007:12:06:59 +0200] "PUT /!svn/wrk/9c36d042-47ac-41d6-a455-b8a6091f6a3c/README HTTP/1.1" 201 225 "-" "SVN/1.4.2 (r22196) neon/0.26.2" 0 svn.example.net
192.0.2.69 - bortzmeyer [29/Mar/2007:12:06:59 +0200] "MERGE / HTTP/1.1" 200 933 "-" "SVN/1.4.2 (r22196) neon/0.26.2" 0 svn.example.net
192.0.2.69 - bortzmeyer [29/Mar/2007:12:06:59 +0200] "DELETE /!svn/act/9c36d042-47ac-41d6-a455-b8a6091f6a3c HTTP/1.1" 204 - "-" "SVN/1.4.2 (r22196) neon/0.26.2" 0 svn.example.net

Il semble y avoir peu de logiciels qui gèrent WebDAV, le principal sur Unix étant cadaver. Voici un exemple d'utilisation de cadaver pour envoyer des fichiers sur un serveur DAV :

% cadaver http://tmp.example.org:9701/tests_perf
Authentication required for Tests de performance on server `tmp.example.org':
Username: tester
Password: 

dav:/tests_perf/>   mput *
[Matching... 4 matches.]
Uploading AFNIC-2-Renater-Paris.pcap.gz to `/tests_perf/AFNIC-2-Renater-Paris.pcap.gz':
Progress: [=============================>] 100.0% of 289 bytes succeeded.
Uploading AFNIC-2-INRIA-Montbonnot.pcap.gz to `/tests_perf/AFNIC-2-INRIA-Montbonnot.pcap.gz':
Progress: [=============================>] 100.0% of 292 bytes succeeded.
Uploading Nerim-2-Renater-Paris.pcap.gz to `/tests_perf/Nerim-2-Renater-Paris.pcap.gz':
Progress: [=============================>] 100.0% of 289 bytes succeeded.
Uploading Nerim-2-INRIA-Montbonnot.pcap.gz to `/tests_perf/Nerim-2-INRIA-Montbonnot.pcap.gz':
Progress: [=============================>] 100.0% of 292 bytes succeeded.

dav:/tests_perf/> quit
Connection to `tmp.example.org' closed.

Mais on trouve du WebDAV en plusieurs endroits, par exemple comme protocole d'accès pour des serveurs de fichiers.

Le groupe de travail WebDAV de l'IETF a eu un parcours assez difficile et vient seulement d'être dissous, après dix ans d'existence, ce qui est extrêmement long pour l'IETF. Finalement, cette mise à jour du RFC 2518 n'apporte que des changements de détails, qui sont décrits dans l'appendice F.


Téléchargez le RFC 4918

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)