Diskussion:WebDAV

Sicherheit

Mir fehlt etwas zum Thema Sicherheit. Es gibt doch verschlüsseltes Webdav. Wie sicher ist das normale Webdav? Welche Clients gibt es? Gruß, Karsten (nicht signierter Beitrag von 78.55.253.35 (Diskussion | Beiträge) 23:07, 19. Okt. 2009 (CEST))

Versionskontrolle

"Zudem ist eine Revisionskontrolle implementiert." Wahrscheinlich ist eine Versionskontrolle gemeint, leider verwenden viele Autoren Version und Revision synonym.tsz 01:07, 18.12.2007

Das ist eine falsche Übersetzung aus dem Englischen. im englischen Sprachgebrauch wird Revision auch gleichbedeutend mit Version verwendet;. Ich habe es korrigiert. --Fomafix 09:20, 18. Dez. 2007 (CET)

Hier fehlen Zeitangaben. Wann waren diese Treffen? ... -- tsor 23:06, 10. Jan 2004 (CET)

lt. diesem Post muss das 1996 gewesen sein. Prüfe ich nachher nochmal. Dann hab' ich auch noch eine Frage... Wie übersetzt man Distributed Authoring ins Deutsche? Ich hab's mal mit Verteiltes Schreiben versucht, aber das hört sich grauenhaft an, und außerdem scheint es eine Wortneuschöpfung meinerseits zu sein. Sollte man es vielleicht bei Distributed Authoring belassen? --Echoray 23:19, 10. Jan 2004 (CET)

Vielleicht könnte noch jemand die Unterschiede (und Vorteile/Nachteile) gegenüber FTP erwähnen, die Frage danach stelle ich mir nämlich auch immer ... --84.167.26.183 17:04, 11. Apr 2005 (CEST)

Struktur, Einführung

Ich habe versucht, dem Artikel etwas Struktur zu geben, da z.B. geschichtliche Hintergründe auch als solche behandelt werden sollten. Hinzu kommt, dass jemand, der der Artikel aufschlägt, um nachzugucken, was WebDAV jetzt eigentlich ist, erst mal lange lesen muss, um eine Antwort zu bekommen. Deswegen habe ich versucht, dass direkt im ersten Absatz kurz zu erklären - bitte korrigieren, wenn das so nicht korrekt ist, weil ich selbst davon kaum Ahnung habe. --Liquidat 19:36, 15. Feb 2005 (CET)

Ressourcen, URIs und unendlich rekursive Definitionen

Steht nun also hier: Ressource ist in diesem Sinn ein HTTP-spezifischer Begriff, der in etwa als »das Ding, auf das ein URI zeigt,« definiert werden kann.

Diese Formulierung erachte ich als etwas merkwürdig und ziemlich rückwärts. Ein URI (Uniform Resource (!) Identifier) ist ja gerade dadurch definiert, daß er auf eine Ressource zeigt :) --Mulk 04:10, 8. Okt 2005 (CEST)

Liste: Server-Applikationen

Ich habe die Liste mit Server-Applikationen, die WebDAV unterstützen gelöscht. Die Liste ist mittlerweile sehr lang geworden, woraus zu schließen ist, das WebDAV-Unterstützung kein sehr spezielles Merkmal ist. Der Informationsgehalt der Liste ist so recht dürftig. --Squizzz 13:01, 5. Jan 2006 (CET)

Vorteile von WebDAV

Hallo,

im Hauptartikel tummeln sich einige komische Sachen bezüglich der Vorteile von WebDAV, vor allem die Kommentare. Da stimmt so einiges nicht oder ist in sich nicht schlüssig - also habe ich sie hier mal aufgeführt:

Text (Behauptung) im Artikel	Kommentar
WebDAV ermöglicht auf einfache Weise Zugriff auf Dateien, die auf einem Internet-Server liegen. Gegenüber der Verbindung mit ftp (bzw. ssh) hat WebDAV verschiedene Vorteile.	Der Vergleich mit Ssh ist sinnlos (angebrachter: Scp, Sftp, verfolgen jedoch andere Ziele), der Satz im Gesamten unbegründet. K: scp beruht auf ssh
Es ist leichter bedienbar, denn es wird von den gängigen Betriebssystemen standardmäßig unterstützt.	Das Argument ist lächerlich; FTP wird auch standardmäßig "unterstützt", die Schwierigkeit der Bedienung hängt vom Client ab
Über WebDAV zugängliche Ressourcen fügen sich nahtlos in den Windows Explorer und den Mac OS X-Finder ein.	Und über FTP zugängliche Ressource fügen sich nahtlos in den Konqueror ein. Die Features von zwei Programmen zu nennen und damit die Vorteile eines Protokolls beleuchten zu wollen ist sinnlos. K: Und über ssh bzw. scp (fish://) zugängliche Ressource fügen sich nahtlos in den Konqueror ein
In vielen neuen Kerneln von Unix-Systemen (z. B. Linux) gibt es bereits Module, die ein Mounten von WebDav-Ressourcen mühelos ermöglichen und so einen uneingeschränkten Zugriff gewährleisten.	Zugegeben, ich kenne eine webdavfs-Unterstützung im Kernel, jedoch kein ftpfs. Das kommt aber sicherlich durch die Verbreitung; FTP-Ressourcen kann man übrigens über Fuse mounten (WebDAV auch). Auch hier: Unterschiedliche Ansätze, Ziele, etc. K: shfs, sshfs
Die Verwendung von WebDAV bereitet auch hinter Firewalls weniger Schwierigkeiten, da es die normalen HTTP-Ports verwendet. Zudem ist das HTTP-Protokoll aufgrund des enormen Internet-Booms verbreiteter als FTP.	Endlich mal gute Argumente. Wobei passives FTP auch nur über einen Port gehen kann (trotzdem bleiben Einschränkungen von sicherheitsfanatischen Admins, die ggf. andere Ports als den TCP-Port 80 sperren)
Kommentare: <!-- was überhaupt nicht stimmt, siehe Diskussion --> <!--- Quelle webdav.org: You can pipeline multiple transfers through a single TCP connection, whereas FTP requires a new connection for each file transferred (plus the control connection). --> <!-- Aber: TCP != HTTP-->	Die Webdav-Quelle hört sich so an, als ob FTP für jede Datei eine neue TCP-Verbindung starten würde, was überhaupt nicht stimmt. Es gibt eine Datenverbindung und eine Befehlsverbindung. Bei WebDAV gibt es nur eine einzige Verbindung, da Befehle und Datenübertragung zusammenfallen. In dieser Hinsicht ist das Argument ausgeschöpft.

Es bleibt zu sagen, dass mir die wirklich schlagkräftigen Argumente für WebDAV und gegen FTP fehlen. Die meisten Dinge kommen wirklich durch die Verbreitung zustande, wobei Konfiguration von Firewalls wesentlich schlagkräftiger als die Funktionalität gewisser Programme ist.

--Benji 00:23, 3. Mär 2006 (CET)

Allerdings, ich muss auch sagen, dass ich den momentanen HTTP/Webbrowser-Hype auch eher kritisch sehe und ich denke, dass es auch einigen anderen so geht. Wäre eventuell einie Kritik-Rubrik angebracht?

--HenningHasemann 17:21 13. April 2006 (CET)

Es sollen hier nicht Argumente für oder gegen WebDAV gefunden werden. Das ist kein Diskussionsforum. Allein stichhaltige Vor- und Nachteile gehören in den Artikel.

--Squizzz 19:22, 13. Apr 2006 (CEST)

Finde dass diese Zeilen mit den Vorteilen von webdav gegenueber ssh und ftp in dieser Form unvollstaendig und verwirrend sind. Was das mit der Revisionskontrolle auf sich hat, wuerde mich da schon mehr interessieren :P (cvs svn fuer ssh -> ok, aber fuer ftp? -> kenn ich nix)

--Dogí 16:00, 1. Maerz 2007 (CEST)

WebDAV Properties

Die Möglichkeit, mit Hilfe der Methoden PROPFIND und PROPPATCH Metadaten von WebDAV-Resourcen zu lesen und zu schreiben, geht in dem Artikel etwas unter. Tatsächlich sind die Operationen zur Verwaltung von Metadaten (zusammen mit den Operationen zur Namensraummanipulation) wesentliches Merkmal von WebDAV. Etwas Ähnliches gibt es nicht in FTP. Zudem unterstützt WebDAV Locking, ein für die Vermeidung des 'Lost Update Problems' unverzichtbares Instrument. Als HTTP-Erweiterung profitiert WebDAV außerdem von der Standardisierung und Erweiterbarkait von HTTP an sich. Außerdem ist das ganze Protokoll XML-basiert, was einen ganzen Haufen weterer Vorteile mit sich bringt.

--Sred 14:15, 15. Mär 2006 (CET)

Nähere DeltaV Beleuchtung

Laut subversion ist der DeltaV standard wenig erfolgreich. Hier ist einiges interessantes dazu nachzulesen: http://svnbook.red-bean.com/nightly/en/svn.webdav.svn-and-deltav.html

Tatsächlich kann ich keine DeltaV server/clients finden. Sollte es tatächlich keine geben, oder nur welche die untereinander nicht kompatibel sind, so wie von subversion behauptet, sollten wir nicht im Artikel deutlich machen, das WebDAV das V eben doch nicht verdient, trotz RFC 3253?

Das V scheint nämlich Quell einiger Konfusion zu sein.

-- Jens Theisen 20:00, 03. Juni 2006 (CET)

Na ja, es gibt ja DeltaV Server und Clients. Aber das sind kommerzielle Produkte, z.B. SAP NetWeaver.

-- Sred 10:54, 27. Jul 2006 (CEST)

Funktionsweise von WebDAV / Nachteil ?

Es ist zwar möglich, mit WebDAV auf entfernte Dateien so zuzugreifen, daß es einem erscheint wie wenn sie auf einem lokalen Datenträger lägen (Laufwerksbuchstabe)... aber ich bin mir nicht ganz sicher, ob es technisch / performance-mäßig das gleiche ist:

Wenn eine Applikation in einer 300 MB großen Datei nur ein Teil lesen will - z.B. 10 MB ab der Position "250 MB" - muß dann bei Nutzung von WebDAV immer die gesamte Datei oder zumindest die ersten 250 MB auch übertragen werden ? (Vermutung: ja, weil es technisch einfach ein http-Download/Upload einer gesamten Datei ist)

Wenn dem so wäre, sollte man dies im Artikel erwähnen.

Ein denkbarer Anwendungsfall ist nämlich: - man hat irgendwo "Speicherplatz" - greift z.B. über ISDn / GPRS / UMTS darauf zu - erstellt dort eine verschlüsste Container-Datei (z.B. mit Truecrypt) - mappt diesen Container als Laufwerk - und greift dann auf einzelne Dateien zu

---> wenn immer der komplette xxx MB große Container gelesen / geschrieben werden muss, wenn auchnur ein einziges Byte einer enthaltenen Datei gelesen/geändert werdenmuss ... dann ist das ein entscheindender Nachteil von WebDAV (oft sogar ein ko-Kriterium)

Interessant wäre es, im Artikel dann auch auf Alternativen zu verweisen, die das besser machen: SMB ? SharePoint Services ? NFS ?

--80.187.124.23 00:10, 16. Jul. 2008 (CEST)

Hallo,

ich denke die Formulierung "es erscheint, als ob man auf einem lokalen Laufwerk wäre" zielt darauf ab, dass WebDAV in vielen Dateisystembrowsern derart integriert ist, dass es kaum mehr auffällt, dass man eigentlich WebDAV benutzt. In dieser Hinsicht unterscheidet es sich z.T. zu der Integration konkurrierender Technologien, z.B. FTP oder rsync.

Selbstverständlich darf man, wenn der WebDAV-Server nicht gerade per Hochgeschwindigkeitsnetzwerk angebunden ist (also z.B. Fast Ethernet-Übertragungsgeschwindigkeiten, die mit aktuellen Festplattengeschwindigkeiten mithalten können), nicht erwarten, mit der geichen Geschwindigkeit und Latenz wie auf einem lokalen Dateisystem arbeiten zu können. Gerade wenn man mit großen Dateien arbeitet, wie es auch bei deinem "Truecrypt-Container"-Beispiel der Fall ist, muss bei jeder Änderung immer die komplette Datei übertragen werden. Prinzipiell wird WebDAV meines Wissens nicht so implementiert, dass sequentieller Schreibzugriff auf Daten möglich ist, da das zudem auch nur relativ wenig Programme machen. Ein Bildbearbeitungsprogramm wird dir beispielsweise normalerweise immer eine komplette Bilddatei einlesen/schreiben, auch wenn sie 300MB groß ist. Prinzipiell bietet HTTP aber die Möglichkeit des sequentiellen Zugriffs, vgl. RFC 2616, Absatz 3.6.1 Chunked Transfer Coding.

Und gerade in dem Punkt gibt es Techniken, die viel eher den Status eines entfernten Laufwerkes für sich beanspruchen könnten. Wie du schon ansprichst, NFS oder SMB (aka CIFS) wären da typische Kandidaten. Vor allem bei Ersterem ist quasi alles auf Dateisystemebene möglich, was auch lokal gemacht werden kann. Diese Protokolle haben aber ein anderes Anwendungsgebiet (eher lokales/Hochgeschwindigkeitsnetzwerk, nur wenige clients). Als andere Alternative, die z.B. viel perfomanter mit großen Dateien umgehen kann und wirklich nur die geänderten Bereiche in großen Dateien überträgt, sei zum Beispiel rsync genannt.

Viele Grüße, --Benji 02:36, 16. Jul. 2008 (CEST)

Ich hätte erwartet das dies mittels des HTTP-Headers Range geschiet, konnte dazu jedoch nichts in den RFCs finden. Weiß das jemand genauer? MaZder 18:56, 22. Nov. 2008 (CET)

Software

Servus!
Ich fände hier einen Überblick über die Software die dieses Protokoll unterstützt praktisch. Möchte mich als DAU nicht darauf stürzen und hoffe, daß das jemand in Angriff nimmt.
Danke voraus.
Gruß, Ciciban 17:26, 18. Feb. 2009 (CET)

WebDAV ist mittlerweile so verbreitet, dass hier eine Aufzählung von Software keinen Sinn macht. Softwareverzeichnisse können das viel besser. -- Stefan Birkner 23:31, 25. Feb. 2009 (CET)

WebDAV im Protokollstack

Im Artikel steht, dass WebDav auf http aufbaut, im Bild des Protokollstacks baut WebDav allerdings direkt auf TCP auf. Finde ich etwas verwirrend, was stimmt denn nun? (siehe auch SOAP) (nicht signierter Beitrag von 193.254.155.48 (Diskussion) 18:16, 21. Jul 2010 (CEST))

• Das wollte ich auch gerade anmerken. Es wird im Artikel mehrfach erwähnt, dass es auf HTTP aufbaut. Insofern sollte man HTTP sowie WebDAV als zwei unterschiedliche "Blöcke" in den Application Layer nehmen (WebDAV natürlich oben ;-) ). Viele Grüße, --192.102.160.65 19:34, 16. Aug. 2010 (CEST)

Nochmal: Sicherheit

Als Vorteil der Benutzung des Port 80 steht im Artikel: "Das Öffnen von zusätzlichen Ports einer Firewall erhöht den Zeit- und Arbeitsaufwand für Systemadministratoren und birgt unter Umständen zusätzliche Sicherheitsrisiken." Ist das nicht eine etwas einseitige Sicht? Immerhin ermöglichst es WebDAV ohne Aufwand große Datenmengen aus einem Firmennetz durch eine Firewall herauszuschleusen, die dafür vielleicht garnicht gedacht ist. --Berthold Werner 08:44, 23. Nov. 2011 (CET)

Könnte dies ein Missverständnis sein?

• Der Passus steht unter "Vorteile". Die Firewall, konfiguriert auf Port 80, müsste schon darauf achten, dass keine unerwarteten Datenvolumina durchflutschen. Das Problem liegt in den Zugriffsrechten, die WebDAV erteilt sind, und der Abschottung. Dies ist aber prinzipiell identisch mit denjenigen, die beim Werbeauftritt der Firma auf HTTP bestehen. Auch an die Firmen-Homepage kann ein Insider eine unverlinkte Unterseite ranbasteln, die Geheimnisse enthält.
• Allerdings ist für einen Insider das Herausschleusen über eine Netzverbindung nicht ratsam, da hier Datenströme und IP-Adressen in Logfiles notiert werden und durch ungewöhnliche Volumina auffallen können, in jedem Fall für lange Zeit Spuren hinterlassen. Dem Insider würde ich raten, mal eben irgendwo einen USB-Stick hineinzustecken. Die Sicherheitsvorteile bei WebDAV lägen in der Abwehr eines Angreifers von außen durch Vermeidung eines zusätzlichen Ports, der es für Menschen unübersichtlicher gestaltet und dadurch immer unbemerkte Lücken wahrscheinlicher macht. Natürlich ist im Moment der Zulassung von WebDAV auch das Sicherheitskonzept nebst Firewall zu revidieren.
• Für Insider ist das Herausschleusen von Datenmengen heutzutage sehr erleichtert worden. USB-Sticks, VPN, Home-Office, Synchronisation mit Laptop-Festplatten und allmählich breites Ausstreuen in irgendwelchen nebligen Clouds schaffen einen Wust an Datenströmen, Arbeitskopien, Zugriffsrechten, Passwörtern – durch die dann kein Admin mehr durchblickt.

LG --PerfektesChaos 12:54, 23. Nov. 2011 (CET)

Danke für die Erklärung. --Berthold Werner 09:32, 24. Nov. 2011 (CET)

• Nicht der „Werbeauftritt der Firma auf HTTP“, nicht die eigene „Firmen-Homepage“ ist das Problem. Wer zu den wenigen Insidern mit entsprechendem Passwort gehört und dort Geheimnisse veröffentlicht, liefert eine perfekte Beweiskette zu seiner Überführung. Das Problem sind Schreibrechte auf irgendwelchen namenlosen fremden WebDAV-Servern im Internet. Irgendeine IP-Adresse mit offenem Webserverport bei irgendeinem Hoster, und am nächsten Tag sind die Server wieder leer und die Daten im Iran, in Nordkorea oder in China.
• Aufgerufene Internetadressen oder gar die zugehörigen Datenströme so zu protokollieren, dass sie Mitarbeitern zugeordnet werden können, ist verboten. Unerkennbar und spontan Uploads durchführen zu können, ist ungleich verlockender, als mit Speichersticks oder gar Festplatten zu hantieren und sie anschließend durchs Werkstor zu tragen. Dass man nach dem Freischalten diverser unverzichtbarer Ports, beispielsweise für das Domain Name System und die Protokolle für E-Mail, mit HTTP und HTTPS an die Grenze seiner Fähigkeiten stößt und mit dem nächsten Port ins Chaos taumelt, ist ziemlich unwahrscheinlich.
• Für Insider unter den Admins gibt es diverse Möglichkeiten, USB-Anschlüsse gezielt zu sperren und Virtual Private Networks sowie Laptops komplett zu abzuschirmen. Für WebDAV setzen sie notgedrungen die aufwändige Deep Packet Inspection ein.

--84.157.192.230 01:01, 17. Feb. 2013 (CET)

Technische Hintergründe

Die Delete Methode ist nicht WebDAV spezifisch, sondern wurde schon in HTTP/1.0 definiert (siehe http://tools.ietf.org/html/rfc1945#appendix-D.1.2 und http://tools.ietf.org/html/rfc2616#section-9.7). Außerdem benutzt die Delete Methode nicht die gleiche Syntax wie die Copy und Move Methode, der Request Header benötigt keinen Destination Eintrag. Ich schlage vor die Delete Zeile zu entfernen. --88.134.191.124 19:52, 10. Jul. 2012 (CEST)

Das verstehe ich jetzt nicht.

• Es wird nirgendwo behauptet, diese HTTP-Methoden wären speziell für WebDAV eingeführt worden.
  • Vielmehr hatte man allgemein bei der Definition von HTTP derartige Anwendungsmöglichkeiten im Sinn.
• Im Artikel heißt es: Zusätzliche Anfrage-Methoden, die von WebDAV-konformen Webservern behandelt werden müssen
  • In der Tat unglücklich ist hier nur das Wort „Zusätzliche“ – es müsste in etwa heißen: Anfrage-Methoden, die von WebDAV-konformen Webservern behandelt werden müssen (teils zusätzlich zu HTTP)
  • Ein normaler Webserver darf auf PUT, DELETE usw. reagieren mit einem 405 Method Not Allowed – auch das steht bereits im Artikel. Ein WebDAV-Server müsste sie umsetzen.

Beste Grüße --PerfektesChaos 20:27, 10. Jul. 2012 (CEST)

Erst beim zweiten Durchgang hat sich mir auch der Sinn des Wortes „Zusätzliche“ erschlossen: Gemeint ist offenkundig „Zusätzlich zu normalen Webservern“ und nicht „Zusätzlich zu HTTP“ – aber das ist tatsächlich nicht sehr klar geschrieben. Magst du Wikipedianer werden und es verbessern? --PerfektesChaos 20:30, 10. Jul. 2012 (CEST)

Offensichtliches Problem dokumentieren

Ein offensichtliches Problem auch für nicht-Experten sollte dokumentiert werden: Man könnte auf die Idee kommen, ein WebDAV-Verzeichnis einen Buchstaben in Windows 7 zuzuweisen (mount). Aber: Wenn man dann einen Abgleich der hochgeladenen Dateien durchführt (z. B. per Totalcommander), fällt der Vergleich auf die Nase, wenn die Dateinamen Sonderzeichen enthält. Die Art und Weise, wie die Sonderzeichen im Ziellaufwerk maskiert werden, scheint sogar implementierungsabhängig zu sein (z. B. NetDrive unter Windows XP benutzt andere Maskierung). D. h. wenn jemand ein WebDAV-Verzeichnis als Backup verwendet, dann macht dies (bei allen Vorteilen bzgl. http: / Port 80 bzw. https:) nur dann Sinn, wenn KEINERLEI Sonderzeichen in den Filenamen enthalten sind. (nicht signierter Beitrag von 78.53.114.236 (Diskussion) 09:56, 30. Jan. 2014 (CET))

Aussprache "WebDAV"

Wie wird in Fachkreisen eigentlich "WebDAV" ausgeprochen: deutsch: Webdaff oder Web-de-a-vau oder englisch Webdäff oder Web-die-äi-wie? Vielleicht könnte man dann den Artikel ergänzen, natürlich nur wenn es einen entsprechenden Beleg gibt ;-) --Exilsaarländer (Diskussion) 08:42, 5. Mär. 2015 (CET)

HTTP Methoden

Der rasante Wuchs des Web in den 1990ern ließ den Gedanken des Distributed Authoring jedoch untergehen, sodass es sich zu dem heutigen, weitgehend nur lesbaren Medium entwickelte. Allerdings enthalten auch die heutigen HTTP-Spezifikationen noch die HTTP-Requests PUT und DELETE, die jedoch von den allermeisten Webservern mit dem HTTP-Statusfehler „405 Method Not Allowed“ abgelehnt werden. Whitehead und seine Mitstreiter haben sich im Rahmen der WebDAV-Arbeitsgruppe das Ziel gesetzt, diese Limitierung aufzuheben.

Sehr fraglicher Absatz, wenn man in 2016 diesen Artikel liest. (nicht signierter Beitrag von 130.149.214.74 (Diskussion) 00:29, 17. Nov. 2016 (CET))

Ich weiß jetzt nicht so genau, was du mit „Sehr fraglicher Absatz“ meinst?

• Ist es dir nicht aktuell genug?

WebDAV verendete 2006/2007 mit einer Spezifikation und kam zu einem technisch stabilen Endpunkt. Man kann es benutzen, mindestens zum Lesen, ja.

Eine Sache hat es aber niemals hinbekommen: Die Schreibberechtigung.

• Der Standard sieht vor, dass jeder Internetbenutzer auf dem Planeten jede über WebDAV zugängliche Datei würde verändern können.
• Auch das gute alte Web Authoring von Tim Berners-Lee Anfang der 1990er ging davon aus.
• Sowas will man aber heute nicht mehr. Böse Angreifer, Schulkinder, Banditen. 1990 waren nur Unis und Militär und Regierungsbeamte und große Firmen am Netz gewesen, mit identifizierbaren Missetätern.
• Man benötigt also eine Benutzerverwaltung, die Benutzer-Identitäten (wer hat die Datei geändert?) und Schreibrechte (darf der das bei dieser Datei überhaupt) im Griff hat.
• WebDAV sieht das nicht vor, und deshalb erfolgt in der Praxis das Schreiben entweder lokal auf die Festplatte oder mittels anderer Mechanismen.

CMS sind gewissermaßen die Nachfolger von WebDAV, die Lesen für alle oder bestimmte registrierte Benutzer, Schreiben für alle oder bestimmte Benutzer auf bestimmte Dateien oder Verzeichnisse zulässt.

• BSCW war wohl eines der ersten volltauglichen Systeme, die das nur per Internet ermöglicht hatten.
• Ältere Systeme sind auf Festplattenzugriff beschränkt und erlauben keine Änderung der Inhalte über HTTP(S), was auch gar nicht so dumm sein muss, so von wegen Sicherheit.
• MediaWiki kann ebenfalls entsprechend konfiguriert werden; privat, öffentlich, pro Seite.
• Du hast es ja gerade benutzt.

VG --PerfektesChaos 10:06, 17. Nov. 2016 (CET)

Kaputter Link?

Weblinks Offizielle WebDAV-Homepage mit Software-Überblick .... diese beiden Links gehen nicht. Grüße xxx