A l'origine pour tester mon serveur WebDAV pour Drupal, j'ai cherché à utiliser le maximum de clients pour ce protocole. L'idée ici est de vous les présenter.
Pour tester la prochaine version de mon module serveur WebDAV pour Drupal, j'ai eu besoin de tester assez systématiquement les clients WebDAV les plus utilisés. Alors autant que cela serve à ceux qui comme moi, ne savent plus bien vivre sans ce protocole.
Un client WebDAV
Un serveur WebDAV est nativement compatible avec la norme HTTP et vous pouvez naviguer en lecture seule sur un partage à l'aide d'un simple navigateur WEB. Cependant, pour pouvoir parcourir, éditer, supprimer, il va nous falloir quelque chose de plus évolué. Et fort heureusement, des clients WebDAV, il y en a pour tous les goûts.
Ici vous trouverez les clients principaux mais il y en a sûrement d'autres. A chaque fois, je fini mon topo par les caractéristiques comparées de chacun des clients. Cela comprend l'identifiant WEB du client, la capacité de garder la connection (keep-alive), la capacité de s'authentifier, d'utiliser un transport crypté, les sessions à base de cookies (évitant une authentification sur le serveur à chaque fois), la compression GZIP et l'utilisation de la propriété displayname. Ce dernier point n'est pas annodin car la base de référence d'une ressource WebDAV est son URI. Or une URI ne peut contenir n'importe quel caractère (genre ;, # ou ?). Et même encodé correctement, certains clients bloquent si l'URI n'est pas en simple ASCII. La propriété displayname permet de définir par ressource (et donc par URI), un nom lisible utilisé pour l'affichage.
DavFS2
DavFS, et son remplaçant, DavFS2, permettent de monter par la commande mount une URL WebDAV comme n'importe quel autre système de fichier Unix. Il utilise en interne la librairie Neon comme Litmus, la suite de test de compatibilité du protocole WebDAV ou encore subversion.
DavFS2 permet donc à toutes les applications de pouvoir bénéficier du support WebDAV sans qu'elles en aient conscience. Pour accélérer les échanges avec le serveur, DavFS2 utilise un système de cache local avec pour inconvénient la non instantanéité des sauvegarde par rapport au serveur. Ceci mis à part, DavFS2 marche merveilleusement. Pour vous connecter à une ressource par ce biais, il faut bien sur installer le paquet favfs2 et taper en tant que root :
mount -t davfs2 http://mon_server/partage /mnt/mon_partage/ -o uid=gaston
Une fois authentifié, le dossier /mnt/mon_partage est prêt à l'emploi. Il est aussi possible de mettre ce type de montage au démarrage de la machine dans /etc/fstab mais à ce moment là, il vous faudra configurer un fichier de secrets contenant vos identifiants. Pour plus d'information, faite man mount.davfs2.
| Identifiant de l'agent | davfs2/1.3.3 neon/0.28.3 |
|---|---|
| Conection continue (keep-alive) | oui |
| Autentification | oui |
| Transport SSL | oui |
| Session (cookies) | non |
| Compression des données | non |
| Display Name | oui, oui, mais il faut ajouter use_displayname=1 dans /etc/davfs/davfs.conf. |
Pour automatiser le montage, il suffit d'ajouter dans /etc/fstab
http://mon_site/dav /media/dav davfs2 auto,user 0 0
Vous pouvez aussi rajouter gid=... et/ou uid=... pour spécifier un groupe ou un utilisateur à qui appartiendra le montage (sinon ce sera root...). Il est aussi possible de remplacer auto par noauto pour ne pas monter le partage au démarrage.
Pour éviter d'avoir à saisir le mot de passe à chaque fois, il faut ajouter le fichier /etc/fstab2/secrets avec quelque chose comme ceci :
"http://mon_site/dav" gaston "mot_de_passe"
Cadaver
Contrairement à DavFS, Cadaver ne cherche pas à "simuler" un système de fichier mais à fournir un interpréteur de commande très similaire de celui d'un client FTP. L'avantage de cette stratégie réside en le fait que les commandes utilisable sont très proches de celles du protocole d'origine.
Pour simplifier l'authentification, Cadaver utilise comme le client FTP, un fichier ~/.netrc qui contiendra une liste d'identifiants sous la forme monsite.com login gaston password un_secret. Ensuite, pour se connecter, il suffit de taper :
cadaver http://mon_site/partage
Collant parfaitement à la norme, ce client est l'outil parfait pour tester un serveur avant de passer à des choses plus lourdes.
| Identifiant de l'agent | cadaver/0.23.2 neon/0.28.3 |
|---|---|
| Connection continue (keep-alive) | oui |
| Autentification | oui |
| Transport SSL | oui |
| Session (cookies) | non |
| Compression des données | non |
| Display Name | non |
Nautilus via GVFS

Je ne reviens pas sur GIO/GVFS, je me suis déjà longuement étendu sur le sujet. Grâce à cette nouvelle structure et le greffon gvfs-dav écrit par Christian Kellner que je remercie ici, Nautilus devient dés-facto un client WebDAV très acceptable. le seul reproche que je pourrais lui faire, mais c'est encore un jeune développement, est sa lenteur souvent liée à un excès de requêtes au serveur. Les futures versions seront sans nul doute plus optimisées.
Pour se connecter, il faut savoir que pour Gnome, le protocole WebDAV ne s'écrit pas webdav:// mais dav:// (et davs:// pour la version sécurisé). Pourquoi ? je n'en sais rien, sûrement une histoire de grand-mère là dessous... Toujours est-il que pour se connecter, il faut saisir dans l'URL de Nautilus quelque chose comme dav://mon_server/. Là les fichiers et dossiers s'affichent, on peut naviguer et lancer par exemple un gedit sur un fichier. La magie GVFS opérant, le contenu devrait s'ouvrir et vous pouvez le modifier et le sauver. De même avec OpenOffice 3.0, Gimp, etc.
Enfin, comme pour la majorité des clients, on regrettera l'absence de la prise en charge de la compression et des sessions. Deux points qui permettent, nous le verront avec d'autres clients, de grandement augmenter les performances. A cela rien d'étonnant sachant que la charge utile des trames WebDAV est formalisée en XML, et que ce texte se compresse à prés de 70%. Ainsi le listing de 300 fichiers qui prenait 200ko, n'en prendrait plus que 20.
| Identifiant de l'agent | User-Agent : gvfs/0.99.7.1 |
|---|---|
| Connection continue (keep-alive) | oui |
| Autentification | oui |
| Transport SSL | oui |
| Session (cookies) | non |
| Compression des données | non |
| Display Name | oui |
Dolphin via KIO

Dolphin semble être devenu pour KDE ce que Nautilus est à Gnome, en moins ergonomique à mon goût. Mais du point de vue WebDAV, le mérite allant à l'excellent KIO_Slave, c'est de loin le meilleur client graphique que j'ai testé. Tout fonctionne à merveille mais surtout de manière très rapide. Et pour cause, c'est le seul, avec DAVExplorer, à prendre en charge la compression et le seul tout court à utiliser les sessions (cookies).
Pour se connecter, l'URL standard est ici webdav://mon_site (ou webdavs:// pour la version cryptée).
| Identifiant de l'agent | mozilla/5.0 (compatible; konqueror/4.1; linux) khtml/4.1.1 (like gecko) |
|---|---|
| Connection continue (keep-alive) | oui |
| Autentification | oui |
| Transport SSL | oui |
| Session (cookies) | oui |
| Compression des données | oui |
| Display Name | oui |
DAVExplorer

Alors Ok, il est très, mais alors très super moche avec son look and fell des années 2000 et ses icônes fauchées à Windows 95. Malgré tout, il mérite l'attention car déjà, écrit en Java, il est totalement cross-plate-formes. Ensuite comme Dolphin, il a pour lui la prise en charge de la compression. Le résultat est une navigation très rapide sur les grands volumes de ressources. A se demander pourquoi les autres ne le font pas.
Maintenant, outre ces nombreux bugs, ce qui rend ce navigateur très particulier est sont extrême prise en compte de la norme WebDav. Les opérations les plus fines sont accessible permettant un contrôle parfait du protocole. Un très bon outil donc à utiliser pour les tests ou lorsque la connection est souffreteuse.
| Identifiant de l'agent | uci dav explorer/0.91 rpt-httpclient/0.3-3e |
|---|---|
| Connection continue (keep-alive) | oui |
| Autentification | oui |
| Transport SSL | oui |
| Session (cookies) | oui |
| Compression des données | oui |
| Display Name | ? |
MacOS/webdavfs 1.3

Nan, je n'ai pas acheté un Mac, j'ai juste découvert que VmWare était parfaitement capable de faire tourner MacOS 10.4.7. Du coup, j'ai pu aller voir ce que valait cet OS tellement ergonomique... Bon, les goûts et les couleurs, on ne va pas s'étendre là dessus. Le truc qui nous intéresse est que cet OS prend en charge nativement WebDAV via le menu Go (pour les gens comme moi, pensez à clicker sur le bureau avant pour que le menu apparaisse...). Ensuite allez sur Connect to server.... Là vous rentrez votre URL à la mode http:// ou https://, vous l'ajouter, vous la sélectionnez et vous clickez sur Connect (je n'ai qu'une version anglaise ;-).
A ce stade la fenêtre d'exploration s'ouvre, et une icône est apparue sur le bureau. Après toutes les opérations sont possibles comme avec Nautilus. Vous pouvez ainsi ouvrir un fichier avec une application de votre choix de manière absolument transparente. Et pour cause, en interne MacOS utilise un bête mount et va donc greffer l'arborescence WebDav dans le dossier /Volumes.
Du coup la même chose est possible en passant par un terminal via GO/Applications/UtilitiesTerminal. Là vous pouvez lancer la commande suivante :
mkdir /Volumes/webdav
mount_webdav http://mon_serveur /Volumes/webdav
...
umount /Volume/webdav
| Identifiant de l'agent | webdavfs/1.3 (01308000) darwin/8.1.0 (x86) |
|---|---|
| Connection continue (keep-alive) | oui |
| Autentification | oui |
| Transport SSL | oui |
| Session (cookies) | non |
| Compression des données | non |
| Display Name | ? |
Windows XP

La bonne nouvelle est que le WebDAV est une notion standard sous Windows. Pas besoin donc d'écumer le net à la recherche d'une installation plus ou moins vérolée. Il suffit d'aller dans la fenêtre du réseau, d'ajouter un nouveau favoris réseau, et de saisir l'URL du serveur sous la forme http://mon_serveur (ou https://). Là le bougre mouline un peu, trouve le titre du serveur et vous propose de créer votre favoris. Ceci fait, une fenêtre s'ouvre sur le serveur et les applications semblent être capable d'ouvrir et les sauver les fichiers sans problèmes.
A notre que ce client a l'identifiant le plus débile que j'ai rencontre, attention les yeux : microsoft data access internet publishing provider protocol discovery... Rien que cela... On dirait le nom complet de Bangkok. Et pour ce prix, il n'y a pas la version...
| Identifiant de l'agent | microsoft data access internet publishing provider protocol discovery |
|---|---|
| Connection continue (keep-alive) | oui |
| Autentification | oui |
| Transport SSL | oui |
| Session (cookies) | non |
| Compression des données | non |
| Display Name | oui |
Conclusion
Dolphin est de loin le plus versatile des clients WebDAV, il prend tout en charge et reste très rapide. Mais nautilus/GVFS est encore jeune et je suis persuadé qu'il devrait rattraper ce retard maintenant que l'infrastructure GVFS est en place.
Côté "autres OS", j'avoue avoir été étonné par Windows pour une fois, il fait le job, sans poser le moindre problème. Un respect des normes qui est à saluer connaissant la triste réputation de Microsoft en le domaine. A noter d'ailleurs que la meilleur documentation du protocole WebDAV est aussi chez eux.
et un peu de PUT pour les formulaires
Généralement pour les formulaires, on utilise plus POST que PUT, non?
Sinon merci pour l'article, très instructif!
@OstenX Tu as absolument raison, je me suis planté. Il y a bien deux méthodes possibles pour expédier le contenu d'un formulaire vers un serveur et ce n'est pas POST et PUT comme je l'avais gardé en tête (d'où ma remarque), mais POST et GET. Le second cas consistant à encoder le contenu du formulaire dans l'URL. Je croyais me souvenir que l'on pouvait poster par un PUT, je me gourrais. Et ce n'est pas si étonnant que cela en fait.
Dans la norme, PUT consiste à Créer ou mettre à jour la représentation d'un document désigné par son URL. Si la représentation n'existe pas, elle est créée, si elle existe, elle est mise à jour. En revanche POST, envoie des informations à destination de l'URL. Ce que l'URL fait de l'information la regarde, elle peut mettre à jour une représentation totalement, partiellement, ou faire totalement autre chose.
Merci à toi, je vais corriger cela.
Personnelement je n'utilise pas (encore) Webdav, qu'apporte-t-il de plus que ssh ?
Pour ce qui est de REST j'aime beaucoup le principe qui reste simple: une ressouce et des méthodes (GET, POST, PUT et DELETE). Une application Restful pourra ainsi tout aussi bien 'discuter' en XML (ou JSON) avec un navigateur/+javascript ou encore avec une autre application Restful . Si ça te dis ... il existe un module restfulifiant les applications catalyst (http://search.cpan.org/~jshirley/Catalyst-Action-REST/) sinon il y a aussi un module REST pour Drupal:)
@Dab les avantages de WebDAV par rapport à SSH :
* disponible en standard sur toutes les plate-formes : linux, windows, mac.
* disponible en standard dans de nombreuses applications comme backend de stockage. Par exemple les calendriers sous Evolution ou thunderbird.
* il est compatible HTTP, ainsi si je n'ai même pas un client webdav, avec un simple navigateur, j'accède à mon système en lecture seule.
* passe à travers les proxy s'ils ne sont pas explicitement configuré comme l'interdisant.
* vu qu'il s'agit d'un protocole, il est possible de virtualiser les fichiers adressés, c'est ce que je fait avec Drupal.
Voilà en gros. Pour moi les deux systèmes sont complémentaires, ssh me permet de travaille entre machines UNIX, pour de l'administration. WebDAV me permet d'exposer la partie système de fichier de notre SI pour récupérer de loin (étranger principalement, mais aussi chez le client).
Un module REST pour drupal ? Hum, je vais aller voir ça ;-)
Mouais !
Sur Windows XP, le client WebDav est assez capricieux: assez difficile à utiliser avec http et des logins+mots de passe (il y a plein d'articles sur le web à ce sujet).
Fonctionne très bien avec https (+ logins) mais par contre il semble que dans ce cas, il ne soit plus possible d'éditer directement les fichiers : il faut les ramener en local, les modifier, et les recopier sur le serveur WebDav ... pas très intéressant (plus de lock pendant la modif).
my2cents,
L@u
@L@u Il est capricieux si le serveur n'est pas prévu pour. Il y a deux astuces, je te l'accord absolument débiles, à y coller pour que le client WebDAV de XP fonctionne correctement. Ceci mis à par, je n'ai pas de problèmes avec ma mouture de serveur WebDAV maintenant j'avoue ne pas savoir ce que cela donne avec Apache/mod_dav.
Maintenant s'il existe un meilleur client sous XP, cela m'intéresse.
Bonjour,
J'ai souci de temps d'affichage en utilisant Webdav sous Windows Xp. Il faut environ 10 mn pour afficher 4800 fichiers pdf (environ 100 Mo)avec l'explorer de Windows.
Est-ce quelqu'un peu me dire s'il y a des problèmes de perf ou des limites au delà d'un certain nombre de fichier ou de volumétrie ? Et comment peut-on améliorer çà (paramétrages, autres client Webdav, etc...) ?
Merci
Le protocole WebDav est basé sur des échanges XML, donc du texte, et pour ce volume de fichier, ça fait un gros fichier texte. Si la compression n'est pas activée du côté serveur, cela peut déjà expliquer en bonne partie ce temps de réponse.
Merci pour ces infos, mais pour vérifier si la compression est activée côté serveur, que dois-je vérifier sur le serveur (quels fichiers de configuration) ?
J'aurais plutôt tendance à vérifier cela du côté client avec un outil comme wget ou lynx.
Le plugin Firefox LiveHttpHeaders fait ça très bien aussi.
Publier un nouveau commentaire