Se connecter à un serveur WebDAV sous Linux, macOS ou Windows

De cURL à Net use

Le 09 juin 2020 à 14h35

4 min

Logiciel

Pour vous connecter simplement à un serveur via internet ou un réseau local vous utilisez quoi ? Dans de nombreux cas, le protocole WebDAV peut être une solution parfaitement adaptée, permettant une gestion des données depuis l'explorateur de fichiers de tous les grands systèmes d'exploitation, mais aussi en ligne de commandes.

Le protocole WebDAV a beau avoir une vingtaine d'années, et être aussi pratique que simple d'utilisation, il est souvent ignoré ou méconnu. Les utilisateurs de NAS lui préfèrent en général SMB/CIFS, alors que pour l'accès distant aux serveurs, beaucoup se reposent encore sur ce bon vieux (S)FTP quand ils n'utilisent pas des méthodes de déploiement moderne.

De son nom complet Web-based Distributed Authoring and Versioning, il s'agit pour rappel d'un complément au protocole HTTP lui ajoutant des commandes permettant le transfert de données depuis ou vers un serveur. Largement complété depuis ses débuts. Ainsi, de nombreux services en ligne proposent encore un accès WebDAV à leurs serveurs.

Cela permet de gérer des fichiers via un point de montage local tant sous Linux, macOS que Windows. Ils deviennent alors utilisables dans de nombreuses applications tierces ou des outils natifs comme l'explorateur de fichiers. Voici un petit guide de la méthode à suivre pour vous connecter à un serveur WebDAV, sur différents OS.

Sous Windows : ligne de commande ou interface graphique

Sous Windows, WebDAV est nativement pris en charge depuis de nombreuses versions de l'OS. Le protocole est géré à la manière de SMB/CIFS, permettant de connecter des « lecteurs réseau ». Cela peut se faire d'un clic droit sur « Ce PC » dans l'explorateur de fichiers, où il faudra préciser l'URL d'accès du serveur, une lettre de lecteur, puis des identifiants :

WebDAV Windows 10

Sinon, on peut passer par la bonne vieille ligne de commande :

net use w: https://webdav.monsiteinternet.fr/data

Et... c'est tout. Une fois le lecteur connecté, vous pouvez y créer, supprimer ou modifier fichiers et dossiers, y déplacer des données, y accéder via d'autres applications, etc. Vous pouvez d'ailleurs doubler cliquer sur un fichier pour le l'ouvrir. Bien entendu, la rapidité dépendra principalement de la qualité de votre connexion internet et de la taille du fichier.

D'un clic droit sur le lecteur réseau vous pouvez le déconnecter, ou via la commande :

net use w: /delete

Sous macOS : simple comme un raccourci clavier

Chez Apple, la commande mount_webdav n'est plus vraiment adaptée. Il faut lui préférer l'interface graphique, là aussi avec l'outil générique de connexion à un serveur (⌘+ K), dans le menu Aller du Finder :

WebDAV macOS

Un élément sera alors ajouté dans les Emplacements. Un clic sur le bouton d'éjection permet de se déconnecter.

Sous Linux (CLI et GNOME)

Finissons par Linux, où les solutions peuvent dépendre de la distribution installée. Pour l'accès en ligne de commande, il faut en général installer un client comme cadaver, dav2fs ou nd. Avec des commandes à adapter selon les cas.

Mais là aussi on a de manière générale accès à une solution via l'interface graphique, comme dans Nautilus pour l'environnement GNOME. Il y a cette fois une subtilité, il faut préciser davs:// en début d'URL plutôt que https:// :

Bonus track : et si on utilisait cURL ?

Il existe de nombreuses applications permettant de se connecter à un serveur WebDAV, d'y gérer ou transférer des fichiers. Mais il y en a une accessible sur de nombreuses plateformes, utilisable en ligne de commande : cURL. Ce qui est logique, puisque cet outil est pensé par nature pour initier des requêtes HTTP.

Ainsi, pour envoyer un fichier sur un serveur via WebDAV, il suffit d'utiliser la commande suivante :

curl -T fichier.ext https://webdav.monsiteinternet.fr/data -u user:password

Pour à l'inverse récupérer un fichier précis :

curl https://webdav.monsiteinternet.fr/data/fichier.ext -u user:password -o fichier.ext

Renommer un fichier :

curl -X MOVE --header "destination:https://webdav.monsiteinternet.fr/data/nouveauFichier.ext" "https://webdav.monsiteinternet.fr/data/fichier.ext" -u user:password

Créer un dossier :

curl -X MKCOL https://webdav.monsiteinternet.fr/nouveauDossier -u user:password

Supprimer un fichier ou un dossier

curl -X DELETE https://webdav.monsiteinternet.fr/data/fichier.ext -u user:password
curl -X DELETE https://webdav.monsiteinternet.fr/data/nouveauDossier -u user:password

Commentaires (32)

Jarodd Abonné

Le 09/06/2020 à 19h34

Perso j’ai eu pas mal de problèmes récemment avec webdav (sous Ubuntu 18.04). La limitation de la taille du cache n’est pas prise en compte, ni le délai d’écriture de log, et comme il y en avait un toutes les 10 secondes, je me suis retrouvé avec un fichier de log de plus de 4 Go !

dj0- Abonné

Le 09/06/2020 à 21h38

Le problème de bus partagé existe aussi sur les pi disposant d’un lecteur de micro sd ? Mon pi2b est monté ainsi, sans disque usb au sens usb-a externe

jpaul

Le 09/06/2020 à 21h47

Niveau perfs le protocole n’a rien de sorcier : c’est de l’HTTP très basique, tu envoies sur une socket TCP quelques headers de requête, le serveur te renvoie quelques headers et le fichier arrive à la suite. La plupart des clients/serveurs supportent le keep-alive. Rien n’empêche les requêtes en parallèle, c’est du HTTP.

En fait comme son nom l’indique c’est vraiment juste purement du web. Donc niveau perfs, le protocole ne va avoir aucun impact. Tout va dépendre de la réactivité du serveur. En 2020 on commence à savoir faire des serveurs http qui poutrent.

Par contre attention à une chose : c’est un avis Perso mais j’ai toujours eu le sentiment que l’implémentation dans Windows était assez « lente » ou du moins avait souvent tendance à planter l’UI pendant que ça charge.

jpaul

Le 09/06/2020 à 21h53

Macarie a écrit :

Personnellement ces protocols finissant par DAV je les aime pas trop (raison ?) un manque de validation en deux étape ^^

David_L a écrit :

Oui ça reste un des problèmes de ce genre de protocole, mais ce n’est pas propre à xDAV, c’est pareil sur plein de protocoles réseau à l’authentification assez basique. 

Est-ce vraiment aux protocoles réseau de gérer des schémas d’authentification complexe ?

L’authentification est un métier suffisamment compliqué pour ne pas en mettre partout. On s’authentifie avant, et on utilise ensuite le protocole avec un token signé à usage limité dans le temps.

fullero

Le 10/06/2020 à 00h21

Le SOC assurerait  lui même le rôle d’ un contrôleur de disque ?

Non, je ne crois pas.

Il me semble que interne ou externe, c’ est toujours sur le même bus usb que c’ est traité et le souci c’ est que le port Ethernet l’ est aussi faute de puce réseau.

Ce serait si cher que cela d’ en mettre une vraie basique plutôt que provoquer des surchauffes du SOC sur les Pi 4 ?

Des fois je me demande comment ils calculent les gains de performance par rapport aux couts …..

David_L Abonné

Le 10/06/2020 à 04h32

Oui, ce que la plupart des implémentations ne gèrent pas, c’est tout le problème. Et c’est ce qui arrive quand on dit “c’est à telle brique de faire le job, pas à la mienne, du coup configurez comme vous voulez c’est pas mon souci). Du coup on se repose sur un serveur HTTP dont les procédure d’auth ne sont pas franchement les plus innovantes par défaut (même si techniquement tout est possible). 

KP2

Le 10/06/2020 à 04h47

fry a écrit :

ça donne quoi coté perfs par rapport à du samba ?

C’est pire…

HTTP est pas vraiment fait pour ça et les implémentations de webdav sont pas top non plus donc… " />

Je crois que webdav est la 1ere incarnation du “HTTP is the new TCP”

David_L Abonné

Le 10/06/2020 à 05h16

Disons que c’est comme dans les débats block/objet. Il n’y en a pas un de mieux que l’autre, il y a différentes solutions pour différents besoins. Mais il y en a toujours pour jouer la carte “pureté”.

iSCSI est plus perf qu’un serveur S3 en théorie, mais bon, à implémenter dans une couche logicielle pour de l’accès aux données avec un bon niveau de flexibilité, c’est pas trop gagné. Là c’est un peu pareil. WebDAV fonctionne avec un peu n’importe quoi (dont cURL, c’est pour ça que je l’ai mentionné dans ce papier) du fait de sa nature HTTP, du moment que le serveur dispose des bonnes directives.

C’est même encore plus large que SMB/CIFS qui est massivement utilisé/implémenté. Si on veut de la perf et grimper à plusieurs Go/s, bien entendu qu’il faudra utiliser autre chose. Tant mieux, ce n’est pas le besoin visé, c’est d’ailleurs le plus souvent utilisé en complément d’une couche de type objet sur les services de stockage.

Après, on peut prier pour que l’accès (S)FTP reste dominant parce que c’est un peu plus proche de la couche hardware, mais je doute qu’on rende service à qui que ce soit.

SebGF Abonné

Le 10/06/2020 à 05h18

La routine habituelle des projets qui ne discutent pas en eux en résumé. " />

David_L Abonné

Le 10/06/2020 à 05h34

Oui et non. Disons que c’est plutôt le souci quand chaque couche est développée de manière isolée, sur de la brique open source, sans réellement quelqu’un qui se préoccupe de la vue d’ensemble. Ce que tu as, enfin parfois, dans des solutions tout-en-un.

Mais soyons clairs : en libre, ça reste mieux… il faudrait juste qu’il y ait un peu plus de coordination globale. Ici on a un bon exemple avec un complément à HTTP, des solutions d’auth à ne plus s’avoir qu’en faire, le W3C qui traine dans le coin, FIDO qui est là, mais bon, tu comprends, WebDAV c’est pas le turfu alors tout ce petit monde ne se préoccupe que de sécuriser l’accès client dans du www, pas trop à des serveurs. 

 On a rencontré le même problème avec OpenSSL qui n'a finalement implémenté U2F (donc même pas FIDO2) qu'au début de cette année, alors que ça faisait des années que les administrateurs de serveurs se reposaient soient sur des solutions sans 2FA, soit de la bidouile plus ou moins bancale (mais bon, comme on en est seulement à commencer à entrevoir la fin de SHA-1 et que ça grogne, on se dit que c'est perdu d'avance )

hurd Abonné

Le 10/06/2020 à 07h30

aureus a écrit :

A noter que, de mémoire, webdav avec du http (et non https) ne fonctionne pas sur windows (p-e en modifiant une clef de registre).

Je confirme que ça se tweak avec une clé de registre, il y à aussi d’autres clés de registres à modifier si on veut envoyé des gros fichiers ou si on veut augmenter le timeout (par défaut 30min).

À noté aussi que l’implémentation interne de windows est assez pauvre en fonctionnalités, elle ne gère pas le “COPY” permettant de faire des copie côté serveur.

aureus a écrit :

Et sur mac mes montages webdav réapparaissaient pas au démarrage de mémoire.

À je connaissait pas ça, faudrait que je re-regarde. Mac Implémente webdav d’une façon particulière, en considérant forcément le disque distant comme un disque local, ce qui fait qu’il créer des fichiers temporaires, ce qui, sur certaines implémentations de webdav, peut devenir pénible.

aureus a écrit :

Pour finir et pour l’anecdote, carddav et caldav sont deux extensions à webdav permettant l’accès aux contacts de messagerie et aux agendas. De moins en moins utilisés à cause de la non utilisation des standards de ms/google mais toujours présent.

Ça marche toujours plutôt bien et il n’y à pas vraiment d’alternative à ma connaissance. Tout comme webdav, c’est pas un protocole terrible vu les différence importante de support, mais ça marche out of the box ou presque sur de nombreux OS et ça passe les NAT et autre facilement.

jpaul

Le 10/06/2020 à 07h51

David_L a écrit :

Oui, ce que la plupart des implémentations ne gèrent pas, c’est tout le problème. Et c’est ce qui arrive quand on dit “c’est à telle brique de faire le job, pas à la mienne, du coup configurez comme vous voulez c’est pas mon souci). Du coup on se repose sur un serveur HTTP dont les procédure d’auth ne sont pas franchement les plus innovantes par défaut (même si techniquement tout est possible).

Bien sûr, mais la solution serait plutôt un standard de pré-authentification à implémenter par les clients (par exemple OAuth > Token > WebDAV). Maintenant je parle de mon idéal, mais je doute que faire évoluer les clients WebDAV fassent partie des priorités des développeurs d’OS.

aureus

Le 10/06/2020 à 08h23

Et dans outlook aussi…

aureus

Le 10/06/2020 à 08h35

hurd a écrit :

Ça marche toujours plutôt bien et il n’y à pas vraiment d’alternative à

ma connaissance. Tout comme webdav, c’est pas un protocole terrible vu

les différence importante de support, mais ça marche out of the box ou

presque sur de nombreux OS et ça passe les NAT et autre facilement.

 Bah malheureusement l’alternative non opensource c’est activesync/googlesync

fry

Le 10/06/2020 à 12h41

c’est sur un pi 4, le réseau n’est plus un bridge (ou je sais plus le terme) sur un port usb, c’est un vrai gigabit qui peut tartiner

idem pour les usb, j’ai pu transférer (rsync) entre 2 DD en usb3 à 70Mo/s en lecture sur l’un et 70 en écriture sur l’autre tout du long (sur des sessions de plusieurs centaines de Go au total)

fry

Le 10/06/2020 à 12h42

ça ressemble aux vagues impressions qui me faisaient penser que webdav était pas top (l’histoire de l’implémentation windows)

aureus

Le 09/06/2020 à 15h33

A noter que, de mémoire, webdav avec du http (et non https) ne fonctionne pas sur windows (p-e en modifiant une clef de registre).

 

Et sur mac mes montages webdav réapparaissaient pas au démarrage de mémoire.

 

Pour finir et pour l’anecdote, carddav et caldav sont deux extensions à webdav permettant l’accès aux contacts de messagerie et aux agendas. De moins en moins utilisés à cause de la non utilisation des standards de ms/google mais toujours présent.

David_L Abonné

Le 09/06/2020 à 15h53

Oui pour CalDAV/CardDAV, on en parle dans un papier à venir ;)

SKN Abonné

Le 09/06/2020 à 16h05

aureus a écrit :

Pour finir et pour l’anecdote, carddav et caldav sont deux extensions à webdav permettant l’accès aux contacts de messagerie et aux agendas. De moins en moins utilisés à cause de la non utilisation des standards de ms/google mais toujours présent.

Avec des passerelles locales genre DavMail, ça reste super pratique pour les accès des agendas exchange avec thunderbird, pas besoin d’extension qui saute a chaque maj..

Edith : citation

Soriatane Abonné

Le 09/06/2020 à 16h16

aureus a écrit :

Pour finir et pour l’anecdote, carddav et caldav sont deux extensions à webdav permettant l’accès aux contacts de messagerie et aux agendas. De moins en moins utilisés à cause de la non utilisation des standards de ms/google mais toujours présent.

C’est une grande perte que Caldav et WebDav ne soient pas pris en charge nativement dans Android à la différence d’iOS.

“It’s not a bug, it’s a feature!!”

fry

Le 09/06/2020 à 16h46

ça donne quoi coté perfs par rapport à du samba ?

j’ai un petit nextcloudpi qui tourne, le “client lourd” (officiel nextcloud) de synchro me semble pas super rapide (et j’avais cru comprendre qu’il tournait sur l’api webdav présentée par nextcloud)

alors que le même pi, via un montage samba du disque ou nextcloud stocke ses données, m’avait l’air largement plus rapide (depuis la même machine sous windows 7)

ubuntu 20.04 intègre directement la connexion à un compte nextcloud, qui apparaît comme un lecteur réseau dans le navigateurs de fichiers, est-ce que ça passe bien par webdav du coup (je vois pas trop ce que ça serait d’autre cela dit)

petit test d’hier soir : ~¹⁰⁄₁₅ Mo/s en wifi, dans les 50Mo/s en rj45 (via l’intégration native d’ubuntu 20.04), j’ai pas testé en samba par contre, d’où la question initiale

anonyme_f525e46a95b50f94ea596fa0bc1b20fd

Le 09/06/2020 à 18h00

David_L a écrit :

Oui pour CalDAV/CardDAV, on en parle dans un papier à venir ;)

Personnellement ces protocols finissant par DAV je les aime pas trop (raison ?) un manque de validation en deux étape ^^

David_L Abonné

Le 09/06/2020 à 18h08

Oui ça reste un des problèmes de ce genre de protocole, mais ce n’est pas propre à xDAV, c’est pareil sur plein de protocoles réseau à l’authentification assez basique. 

Altair31

Le 09/06/2020 à 18h28

Macarie a écrit :

Personnellement ces protocols finissant par DAV je les aime pas trop (raison ?) un manque de validation en deux étape ^^

Le problème est que le 2FA est beaucoup trop récent par rapport au WebDAV. Du coup il ne fait pas (encore?) parti du standard.

Après Nextcloud est basé sur WebDAV et peux proposer du 2FA

fry a écrit :

ça donne quoi coté perfs par rapport à du samba ?

j’ai un petit nextcloudpi qui tourne, le “client lourd” (officiel nextcloud) de synchro me semble pas super rapide (et j’avais cru comprendre qu’il tournait sur l’api webdav présentée par nextcloud)

alors que le même pi, via un montage samba du disque ou nextcloud stocke ses données, m’avait l’air largement plus rapide (depuis la même machine sous windows 7)

ubuntu 20.04 intègre directement la connexion à un compte nextcloud, qui apparaît comme un lecteur réseau dans le navigateurs de fichiers, est-ce que ça passe bien par webdav du coup (je vois pas trop ce que ça serait d’autre cela dit)

petit test d’hier soir : ~¹⁰⁄₁₅ Mo/s en wifi, dans les 50Mo/s en rj45 (via l’intégration native d’ubuntu 20.04), j’ai pas testé en samba par contre, d’où la question initiale

Un truc qui peut grandement ralentir WebDAV lors du versement de fichier, c’est les limites imposées par le serveur web sur la quantité de données envoyées à chaque requête.

Après sur un Pi, il ne faut pas aussi oublier que ton disque dur est en USB et sur le même bus que les cartes réseaux.

fry

Le 10/06/2020 à 12h56

David_L a écrit :

j’ai toujours l’impression qu’utiliser http pour autre chose que du texte c’est “contre nature” et pas optimisé

par “texte” j’entends tout ce qui est web, le html, css, javascript, json …

dès qu’il faut jouer avec des fichiers je trouve ça suspect, même un simple champ “file” dans un formulaire j’ai l’impression que c’est de la bidouille sur un truc qui le prévoyait pas au début, et qui est pas vraiment prévu pour des grosses volumétries

y’a qu’a voir les valeurs par défaut quand on installe apache, php et compagnie, 2Mo, en texte c’est bien, en fichier “media” on va pas super loin

cela dit, ayant constaté que mon montage à base de pi tenait les 50Mo/s, vraisemblablement via webdav, c’est pas si mal, mais je me demandais si avec le même matos du samba “de base” fournirait du 95Mo/s ou du 55Mo/s

y’a peut-être des configurations à faire, mais je sais pas si c’est nextcloud, webdav, ou le pi (raspbian/raspberry pi os / nextcloudpi) qui va être le plus compliqué

note que j’ai constaté tardivement, l’image nextcloudpi est basée sur raspbian, donc en 32bits, y’a peut-etre moyen de tirer mieux parti du matos si ça tournait sur la version arm64 au lieu de armhf, et j’ai un souci qui fait qu’en upload les fichiers sont tronqués à 2.1Go (alors que les rsync de fichiers >4Go ne posent aucun pb, et que je peux les récupérer)

Ced-le-pingouin Abonné

Le 10/06/2020 à 13h13

Ah, il faudrait peut-être que je réessaye. Ca fait une éternité que j’ai pas testé ce protocole.

Indépendamment des comparaisons avec Samba et des questions de vitesse/auth à cause du http, quand j’avais essayé WebDAV, il y a sans doute plus de 10 ans, bah c’est carrément au niveau stabilité et ergonomie que ça n’allait pas du tout.

Peut-être qu’il y avait moins de clients, et/ou qu’ils étaient moins matures. Et surtout, il me semble qu’à l’époque il était hors de question que ce soit intégré à l’explorateur de fichiers, ce qui le rendait plutôt balourd par rapport à Samba.

Mais de mémoire je l’avais testé parce que Samba, derrière un pare-feu ou entre des réseaux différents, c’était plus compliqué.

David_L Abonné

Le 10/06/2020 à 13h51

fry a écrit :

j’ai toujours l’impression qu’utiliser http pour autre chose que du texte c’est “contre nature” et pas optimisé

par “texte” j’entends tout ce qui est web, le html, css, javascript, json … 

Du coup, les images et vidéos d’une page web, tu les charges avec quoi ? Un lien FTP ? " />

fry

Le 10/06/2020 à 22h15

grmblh, touché

d’un autre coté, le streaming est assez récent (bon ok on dépasse les 10 ans quand même, mais c’était quand même laborieux au début il me semble)

pour les images, “normalement” sur le web on évite les images trop lourdes, donc même si le http est / était moins performant, c’est presque pas visible.

du moins dans le sens serveur => client

quand on dépose des fichier, donc dans le sens client => serveur, faut toujours des trucs spécifiques (manipuler des fichiers “reçus” (du point de vue du serveur) en php est une plaie, surtout si on s’attaque à des gros fichiers, faut jouer avec les max_upload et autres conf, si on veut avoir un retour sur la progression faut jouer avec du js/ajax etc …)

ça sort du protocole c’est sur, mais au moins en php, qui me semble quand même le plus accessible pour faire des choses avec du http, c’est pas génial

KP2

Le 11/06/2020 à 07h39

David_L a écrit :

Disons que c’est comme dans les débats block/objet. Il n’y en a pas un de mieux que l’autre, il y a différentes solutions pour différents besoins. Mais il y en a toujours pour jouer la carte “pureté”.

La question du block/objet est relativement récente à coté de Webdav… D’ailleurs, je pense que si AWS a préféré pondre une solution maison pour S3, c’est peut-être pas pour rien " />

David_L a écrit :

iSCSI est plus perf qu’un serveur S3 en théorie, mais bon, à implémenter dans une couche logicielle pour de l’accès aux données avec un bon niveau de flexibilité, c’est pas trop gagné. Là c’est un peu pareil. WebDAV fonctionne avec un peu n’importe quoi (dont cURL, c’est pour ça que je l’ai mentionné dans ce papier) du fait de sa nature HTTP, du moment que le serveur dispose des bonnes directives.

Tu peux pas comparer iSCSI et S3 ou Webdav… c’est effectivement utilisé pour des besoins tellement différents…

David_L a écrit :

C’est même encore plus large que SMB/CIFS qui est massivement utilisé/implémenté. Si on veut de la perf et grimper à plusieurs Go/s, bien entendu qu’il faudra utiliser autre chose. Tant mieux, ce n’est pas le besoin visé, c’est d’ailleurs le plus souvent utilisé en complément d’une couche de type objet sur les services de stockage.

Le problème est là, pour moi, c’est qu’on place (ou “on a placé”) trop souvent webdav face à smb/cifs (et le commentaire auquel j’ai répondu était aussi dans cette vision) or déjà que SMB/CIFS est pas très bon coté perf (essentiellement à cause de son overhead) mais Webdav n’est bon ni en perfs ni en fonctionnalités.

Il est potable pour les utilisations “objets” mais il s’est fait déglingué par S3 qui est devenu un standard de fait.

David_L a écrit :

Après, on peut prier pour que l’accès (S)FTP reste dominant parce que c’est un peu plus proche de la couche hardware, mais je doute qu’on rende service à qui que ce soit.

FTP est mort. SFTP restera pour les usages techniques de part son très bon niveau de sécurité mais ça n’ira pas plus loin…

KP2

Le 11/06/2020 à 07h57

fry a écrit :

j’ai toujours l’impression qu’utiliser http pour autre chose que du texte c’est “contre nature” et pas optimisé

par “texte” j’entends tout ce qui est web, le html, css, javascript, json …

dès qu’il faut jouer avec des fichiers je trouve ça suspect, même un simple champ “file” dans un formulaire j’ai l’impression que c’est de la bidouille sur un truc qui le prévoyait pas au début, et qui est pas vraiment prévu pour des grosses volumétries

C’est pas si contre nature. HTTP a été conçu pour transmettre des fichiers… mais plutot dans un seul sens en fait. Quoique l’upload est arrivé très vite si ma mémoire est bonne…

Non, c’est pas ça qui me pose problème avec Webdav. Le principal problème de webdav, c’est ses fonctionnalités qui sont justes nulles : la gestion des droits est quasi inexistante par exemple. Au point que DOS peut rivaliser avec, on dira… mais y’a plein d’autres trucs sur les accès concurrents, les métadonnées, etc

Un bon protocole de partage de fichiers (sur LAN) doit présenter des fonctionnalités presque au même niveau qu’un système de fichiers (ce que fait NFS par exemple mais aussi SMB) et à la fois en lecture ET en écriture donc être assez bas niveau et avec un overhead faible pour les perfs. HTTP n’est pas du tout fait pour ça. Webdav est vraiment une verrue et c’est d’autant plus sale qu’il a été conçu à une époque où on était très loin de parler de stockage objet “à la S3”.

Et d’ailleurs, lorsque le besoin de stockage objet s’est fait sentir, Webdav était trop mal foutu pour ça aussi (trop vieux en fait) donc Amazon a préféré une solution nouvelle et maison : S3 (fait avec une API et HTTP directement).

Résultat, Webdav n’a jamais été bon pour quoique ce soit quelque soit le moment… Pas étonnant qu’il ne serve quasiment à rien (il sert pour les calendriers et les contacts - et encore, il a fallu le transformer en CalDAV et CardDAV…)

Bon, j’ai pas la haine envers WebDAV, c’est juste une bonne idée arrivée trop tôt et qui n’a pas été poussée jusqu’au bout. C’est un truc hyper intéressant sur le papier mais on découvre vite les limites lorsqu’on essaye de le mettre en oeuvre (et qu’on dépasse le simple stade du PoC).

Oui voilà en fait : WebDAV est un bon outil de PoC et c’est là qu’il est d’autant plus décevant, c’est qu’il parait cool en PoC mais quand on passe a l’étape suivante, on déchante et on est obligé de tout revoir.

fry

Le 11/06/2020 à 08h44

merci pour cette analyse / résumé / infos :)

Loufute

Le 12/06/2020 à 08h32

J’ai dans ma To Do liste d’installer un serveur CalDav sur mon Mint pour tenter une synchronisation locale de mes calendriers iOS, mais la premier (et dernière à ce stade " /> ) fois que j’avais tenté, je n’avais pas su installer CalDav. J’espère que votre papier pourra m’aider à y voir plus clair " />