Entwurf:Netzwerke:Webdav

Aus ITWiki
Zur Navigation springen Zur Suche springen

1 Technische Hintergründe

  • Das WebDAV-Protokoll erweitert das vorhandene um einen Satz neuer Methoden und Header-Attribute.
  • Zusätzliche Anfrage-Methoden, die von WebDAV-konformen Webservern behandelt werden müsse
HTTP-Methode Beschreibung
PROPFIND wird benutzt, um Eigenschaften, abgelegt als eines entfernten Systems in Erfahrung bringen zu können
PROPPATCH ändert und löscht mehrere Eigenschaften einer Ressource in einer einzigen Anfrage (einem „“)
MKCOL erstellt ein Verzeichnis (bei WebDAV „Collection“ genannt)
COPY Kopiert eine Ressource, die Dateinamen werden dabei in Form einer angegeben
MOVE Verschiebt eine Ressource (mit der gleichen Syntax wie COPY)
DELETE Löscht eine Ressource (mit der gleichen Syntax wie COPY)
LOCK Weist den Webserver an, die Ressource zu . Damit soll verhindert werden, dass die Ressource auf dem Server anderweitig bearbeitet wird, während der anfragende Client das tut.
UNLOCK Entfernt die Sperre wieder
  • Ressource ist in diesem Sinn ein HTTP-spezifischer Begriff, der in etwa als „das Ding, auf das ein zeigt“ definiert werden kann.
  • Dabei handelt es sich in der Regel um Dateien auf dem Webserver.

1.1 WebDAV und Reverse Proxy

WebDAV lässt sich auch hinter einem :

– cache_peer webserver ..... login=PASS

1.2 Implementierungen

  • WebDAV ist in allen gängigen -Distribution.

2 WebDAV

2.1 Grundlagen

WebDAV ist eine interessante technische Möglichkeit, um Dateien und Ordner auf entfernten Rechnern abzulegen – im Prinzip also nichts anderes als das, was auch ftp und ssh ermöglichen. Also nichts Neues – oder doch? Wir wollen im Folgenden diese Technik genauer betrachten sowie die Stärken und Schwächen beleuchten. Des Weiteren betrachten wir die Voraussetzungen, die Sie auf der Client-Seite benötigen.

2.1.1 Erweiterung von HTTP

WebDAV (Web-based Distributed Authoring and Versioning) ist eine Erweiterung des Protokolls HTTP/1.1 und ein offener Standard zur Bereitstellung von Dateien im Internet. Hierbei werden bestimmte Einschränkungen von HTTP aufgehoben, und die Benutzer können auf ihre Daten wie auf eine Online-Festplatte zugreifen. Bei regulärem HTTP ist es nur möglich, einzelne Daten hochzuladen (z. B. in Formularen); mit WebDAV gibt es hier keine Grenzen – bis hin zum Verschieben von ganzen Verzeichnissen. Des Weiteren ist eine Revisionskontrolle ähnlich wie cvs oder svn implementiert.

An der Tatsache, dass es sich bei WebDAV »nur« um eine Erweiterung des HTTP-Protokolls handelt, kann man den wesentlichen Vorteil dieser Technik erkennen: Es nutzt den Standard-HTTP-Port (meist 80/TCP). Dadurch kann es in der Regel auch verwendet werden, wenn sich zwischen zwei Rechnern eine Firewall befindet. Bei anderen Übertragungsmethoden wie dem File Transfer Protocol (FTP) oder ssh müssen vielfach zusätzlich Ports der Firewall geöffnet werden. Dies bringt zwar meistens kein erhöhtes Sicherheitsrisiko mit sich, erhöht aber den Zeit- und Arbeitsaufwand, um eine Verbindung zu ermöglichen. Die erwähnte Revisionskontrolle ist weder bei ftp noch bei ssh »out of the box« möglich.

2.1.2 Entwicklung

Die Entwicklung von WebDAV begann im Jahre 1995, als sich mehrere Unternehmen und Organisationen (DARPA, Microsoft, Netscape, Novell, U.C Irvine, W3C, Xerox) unter der Führung von Jim Whitehead zusammenschlossen. Heute sind an WebDAV drei Arbeitsgruppen der IETF (Internet Engineering Task Force) beteiligt. Sie bilden gemeinsam die WebDAV Working Group, die DASL Working Group und die Delta-V Working Group. Das Ziel wurde bereits 1995 vereinbart und bestand in einem »editierbaren« Web.

Es wurde ziemlich schnell klar, dass das letztendliche Ergebnis dieser Arbeitsgruppe eine Erweiterung des HTTP-Protokolls sein würde (siehe hierzu Abschnitt 26.1, »Das HTTP-Protokoll«). Zu Beginn stand die Entwicklung des Distributed Authorings im Vordergrund. Die Funktionalität der Versionskontrolle wurde erst später in das System integriert. Detaillierte Informationen über die Anforderungen und die Spezifikationen des Protokolls sind in den beiden Dokumenten RFC 2291 (Anforderungen) und RFC 2518 (Protokoll) zu finden. Derzeitige Arbeiten konzentrieren sich auf eine Reihe von Erweiterungen, wie z. B. Authentifizierung, Redirection-Kontrolle und Sortierung von Einträgen in Collections.

2.1.3 Technische Hintergründe

WebDAV ist wie erwähnt eine Erweiterung von HTTP und benutzt hierfür XML (ExtensibleMarkup Language). Diese Methoden sind für die Gewährleistung der neuen Funktionalitäten (Locking, Propertys, Collections) notwendig. HTTP selbst definiert acht Methoden:* GET / PUT / DELETE – Eine Ressource anfordern, schreiben oder löschen (WebDAV: DELETE – eine Collection löschen)

  • POST – Informationen an den Browser übermitteln (Formulardaten u. Ä.)
  • HEAD – Ähnlich wie GET. Der Unterschied besteht darin, dass das System in seiner Response keinen Message-Body zurückgeben muss.
  • OPTIONS – Information über eine Kommunikation anfordern, ohne eine Aktion auszuführen
  • TRACE – Für Test- und Diagnosezwecke (Request/Response-Kette prüfen)
  • CONNECT – Reserviert für das Tunneling bei Proxys

Weitere sieben Methoden werden speziell von WebDAV definiert:* LOCK – Setzt für den Überschreibschutz eine Sperre auf eine Collection oder Ressource.

  • UNLOCK – Gibt eine gesperrte Collection oder Ressource wieder frei.
  • PROPFIND – Liest Meta-Daten von Ressourcen oder Collections.
  • PROPPATCH – Schreibt Meta-Daten von Ressourcen oder Collections.
  • COPY – Kopiert Collections und Ressourcen innerhalb eines zusammenhängenden Namensraumes.
  • MOVE – Verschiebt Collections und Ressourcen innerhalb eines zusammenhängenden Namensraumes.
  • MKCOL – Erzeugt eine neue Collection.

2.1.4 Aktuelle Möglichkeiten

Im Großen und Ganzen sind es drei Anwendungsgebiete, auf denen WebDAV seine Vorteile ausspielen kann:# Vereinfachung des Publizierens auf Webservern
Erstellte Dokumente mehrfach zu transformieren und dann per FTP auf den Webserver hochzuladen ist ein umständlicher Weg. WebDAV bietet hier die Möglichkeit, Dateien bequem auf Webservern zu verwalten. Damit ist das Publizieren und die Versionskontrolle von Webseiten so einfach wie das Speichern auf der eigenen lokalen Festplatte.

  1. Arbeitsgruppen
    Die Arbeit von Arbeitsgruppen ist wesentlich effizienter geworden. Anstatt einzelne Dokumente zwischen den Gruppenmitgliedern per E-Mail zu verschicken, können Sie diese direkt über die Seite verschieben, die Sie gerade bearbeiten. Der Locking-Mechanismus schützt dabei vor unerwünschten Zugriffen und dem Überschreiben von Änderungen.
  2. Content-Management
    In Verbindung mit WebDAV-fähigen Content-Management-Applikationen können einzelne Eigenschaften mit beliebigen Web-Ressourcen verknüpft werden. So können Sie z. B. einzelne Dateien indizieren und eine Auswahl nach dem Autor oder nach Kombination der Key-Wörter usw. durchführen.

2.2 Konfiguration

Um WebDAV nutzen zu können, brauchen Sie einen Client und einen Server, der dieses Protokoll unterstützt. Wir gehen zunächst auf die Client-Seite ein. Viele Provider und E-Mail-Anbieter stellen ihren Nutzern WebDAV zur Verfügung. Einen kostenlosen Testzugang erhalten Sie z. B. bei www.venuecom.com. Wenn Sie z. B. ein Postfach bei web.de oder gmx.de besitzen, kommen Sie auch bei diesen Anbietern zu entsprechendem Platz. Mit modernen Windows- und Linux-Versionen ist ein Zugriff auf solche WebDAV-Server kein Problem. Wir werden im Folgenden die verschiedenen Möglichkeiten besprechen, mit denen Sie Zugriff auf WebDAV haben. Die technische Grundlage all dieser Möglichkeiten ist die Bibliothek libneon.

2.2.1 Mit Cadaver auf WebDAV zugreifen

Der Klassiker unter den Zugriffsmöglichkeiten ist Cadaver, ein Tool für die Kommandozeile. Sie können sich die aktuelle Version unter www.WebDAV.org/cadaver/ herunterladen, aber dieses Tool ist in allen großen Distributionen enthalten. In Debian-basierten Distributionen ist meist aus lizenzrechtlichen Gründen der SSL-Support nicht enthalten, da hilft dann nur, es selbst zu kompilieren. Die Bedienung ist außerordentlich einfach. Mit einem

cadaver https://www.WebDAV.de

verbinden Sie sich mit dem Server, und mit den Befehlen put (hochladen) und get (herunterladen) tauschen Sie Dateien aus. Ansonsten navigieren Sie auf dem WebDAV-Server wie gewohnt, also mit ls, cd usw. Konsultieren Sie die Manpage für weitere Informationen.

2.2.2 Ein WebDAV-Verzeichnis einhängen

Um ein WebDAV-Verzeichnis per Konsole zu mounten (am besten in das Verzeichnis /media/), benötigen Sie das Paket davfs2:

sudo apt-get install davfs2

Danach legen Sie im Verzeichnis /media/ ein entsprechendes Verzeichnis an, in dem Sie dann die WebDAV-Verbindung realisieren:

sudo mkdir /media/VerzeichnisName

Jenes Verzeichnis sollte dann mit eingeschränkten Rechten versehen werden, sodass die oder der Benutzer allenfalls darin schreiben dürfen. In diesem Fall bekommen alle Benutzer Lese- und Schreibrechte:

sudo chmod 0766 /media/VerzeichnisName

Wird dieser Befehl vergessen, kann das Laufwerk zwar eingehängt werden, aber niemand außer Root darf darin schreiben. Nun können Sie das Verzeichnis mounten, sodass es sich fast wie ein lokales Laufwerk bedienen lässt:

sudo mount -t davfs https://www.zieladresse.ch /media/VerzeichnisName/

Jetzt können Sie Daten per Drag & Drop auf das Verzeichnis verschieben. Die Technik verwendet einen Cache-Speicher zur Beschleunigung.

Falls das Verzeichnis dauerhaft eingebunden werden soll, bietet sich eine Lösung mit der Datei fstab an. Um das Verzeichnis wieder sauber auszuhängen, müssen Sie erneut einen Befehl per sudo abgesetzen:

sudo umount /media/VerzeichnisName

Es kann allenfalls einen Moment dauern, bis das Laufwerk ausgehängt wird, da der Cache je nachdem noch übertragen werden muss.

2.2.3 GNOME

GNOME integriert von Haus aus alle notwendigen Voraussetzungen für einen leichten Umgang mit WebDAV. Der Dateimanager Nautilus ist hier das Werkzeug der Wahl. Sie müssen lediglich den WebDAV-Server als neuen Zugriffsort angeben. Um dieses Ziel zu erreichen, gibt es prinzipiell zwei Möglichkeiten. Zum einen können Sie auf dem Desktop unter Orte · Verbindung zu Server... den WebDAV-Server eintragen, oder Sie nutzen den gleichen Dialog in einem beliebigen Nautilus-Fenster unter Datei · verbinden....

Datei:Bild28.png

»WebDAV«-Server unter GNOME einbinde

GNOME unterstützt bei beiden Methoden sowohl gesicherte (WebDAVs://) als auch ungesicherte Verbindungen (WebDAV://). Wenn Sie alle Verbindungsdaten eingegeben haben, erscheint die Verknüpfung zum Server auf dem Desktop.

Wenn Sie diese Verbindung wieder lösen möchten, reicht ein Rechtsklick auf das zugehörige Icon und ein Anklicken des Menüpunkts Datenträger aushängen. Leider ist GNOME bei manchen Web-Server-Konfigurationen nicht in der Lage, sich das Passwort zu merken.

Datei:Bild29.png

Abbildung 26.6 Definition von Servern in »Nautilus«

2.2.4 KDE

Unter KDE gestaltet sich die Integration von WebDAV ähnlich einfach wie unter GNOME. Hier nutzen Sie das Pendant zu Nautilus, den allmächtigen Konqueror. In diesem müssen Sie lediglich die Adresse des Servers in die Adressleiste eingeben. Bei der nachfolgenden Abfrage können Sie entscheiden, ob sich der Konqueror den Benutzernamen und das Passwort merken soll. Der »Datei-Eroberer« von KDE agiert hierbei vorbildlich und ist einfacher zu bedienen als Nautilus.

Datei:Bild30.png

Der »Konqueror« beherrscht »WebDAV« ebenfalls standardmäßig.

Datei:Bild31.png

Abbildung 26.8 Der Umgang des »Konqueror« mit einem »WebDAV«-Server ist selbsterklärend.

Linux:Befehl:cadaver

2.3 Zugriff auf Webdav

3 WebDAV-Server

This can be combined with user authentication (using LDAP or a number of other password mechanisms).

3.1 WebDAV Server Installation

3.1.1 Install Apache webserver

Apache2 must be installed, either alone or as part of a LAMP server.

# APT install apache2

or

apt-get install tasksel
tasksel install lamp-server

3.1.2 Open your firewall

  • Remember, WebDAV is an HTTP server. The incoming default HTTP and/or HTTPS ports (80 and/or 443) should be open to the server.
  • It is, of course, also possible to use custom ports by changing the allowed incoming ports in the firewall, the virtual host configuration file, and, of course, the URL used to reach the WebDAV server.

3.1.3 Enable the Apache2 WebDAV modules

Enable the dav and dav_fs modules:

# a2enmod dav_fs

Restart Apache2

# systemctl restart apache2

3.1.4 Create a folder for WebDAV use

There are two options: * Create a WebDAV directory in the /var/www folder: sudo mkdir /var/www/WebDAV1 or Create a WebDAV directory in the /home/user/ (also known as ~/) folder and create a symbolic link: mkdir ~/WebDAV1 sudo ln -s ~/WebDAV1 /var/www/* Create a subdirectory for files: mkdir /var/www/WebDAV1/files* Note: In the next several steps, file/folder ownership and permissions can also be adjusted from a File Manager (such as Dolphin in Kubuntu or Nautilus in Ubuntu) as root: sudo dolphin or sudo nautilus* Make sure the owner of whichever WebDAV folder was created (and its subfolders, using the -R recursive switch) is www-data (the user ID for Apache2) and the group is that of your user ID (or, alternatively, root): sudo chown -R www-data:user /var/www/WebDAV1 or sudo chown -R www-data:user ~/WebDAV1

Alternatively you could create a WebDAV user group so that some group of local users could access the files locally (instead of through WebDAV). Add the individual users to that group and use WebDAV as the group instead of a single user (or root), for example:

sudo chown -R www-data:WebDAV /var/www/WebDAV1* To allow files in the WebDAV folder (and its subfolders, using the -R recursive switch) to be Read/Write but not eXecutable (which may be a security risk on some servers):

sudo chmod 664 -R /var/www/WebDAV1

or

sudo chmod 664 -R ~/WebDAV1* Some users find that broader permissions may be required, and instead allow Read/Write/eXecute for the Owner / Group (but not all users):

sudo chmod 770 -R /var/www/WebDAV1

or

sudo chmod 770 -R ~/WebDAV1

3.1.5 Create or edit the virtual host file

  • Edit the virtual host (vhost) file used for the URL through which WebDAV will be accessed
#  kate /etc/apache2/sites-available/mydomainhost

where mydomainhost is the name of the virtual host configuration file used for your URL. If you are using the default virtual host file, edit that one.

Add the line

Alias /WebDAV1 /var/www/WebDAV1/files

so that accessing the WebDAV folder using the URL

http://myhost.mydomain.org/WebDAV1

will forward to the correct folder (/var/www/WebDAV1) on the computer. * The final virtual host file ought to resemble:

<VirtualHost *>
#
# UseCanonicalName off
# ServerName WebDAV1.mydomain.org
ServerName myhost.mydomain.org
ServerAlias 192.168.0.155 WebDAV1.mydomain.org
#
ServerAdmin root@localhost
DocumentRoot /var/www/
#
Alias /WebDAV1 /var/www/WebDAV1/files
#
 <Directory /var/www/WebDAV1/>
  Options Indexes MultiViews
  AllowOverride None
  Order allow,deny
  allow from all
 </Directory>
</VirtualHost>
  • In this example, the WebDAV server is on the primary server, so the URL is the same as that of the primary server (and would be accessed from http://myhost.mydomain.org/WebDAV1).
  • The primary server's IP address on the LAN (in this example) is 192.168.0.155, so to access it from the LAN, this address could also be used: http://192.168.0.155/WebDAV1. *

Enable the virtual host (vhost):

# ln -s /etc/apache2/sites-available/mydomainhost /etc/apache2/sites-enabled/* 

Restart Apache2:

# /etc/init.d/apache2 restart* 

Test that the folders are reachable through Apache2 using:

http://localhost/WebDAV1 

or http://192.168.0.155/WebDAV1

3.1.6 Create password access for the WebDAV folders

  • Note: This method uses HTTP Basic Authentication as outlined in the Apache documentation. However, this same documentation recommends against routine use of HTTP Basic Authentication (which transmits unencrypted passwords, inviting password sniffing) and instead recommends HTTP Digest Authentication (or at least HTTP Basic Authentication over SSL). Refer to the Apache documentation for more details.
  • Create the WebDAV password file /var/www/WebDAV1/passwd.dav with the user testuser. For more info see here. (The -c switch creates the file if it does not exist.):

sudo htpasswd -c /var/www/WebDAV1/passwd.dav testuser

Type in a password for the user testuser.

We will later use this userID when connecting to the WebDAV URL:

http://myhost.mydomain.org/WebDAV1 * Add other users (e.g. testuser2, testuser3, etc.) as needed. (Omit the -c switch because the password file already exists.)

sudo htpasswd /var/www/WebDAV1/passwd.dav testuser2

Note: See below for adding a password for users accessing WebDAV folders from Windows clients. * Change the permissions of the /var/www/WebDAV1/passwd.dav file so that only www-data (as owner) and user (or, alternatively, root) as the group can access it:

sudo chown www-data:user /var/www/WebDAV1/passwd.dav sudo chmod 660 /var/www/WebDAV1/passwd.dav

Note: I personally use chmod 460, which does not allow the www-data owner to write to the file (only read permissions are allowed). Only members of the local group user can read/write to the file using this chmod 460 setting. * Edit the virtual host (vhost) file /etc/apache2/sites-available/mydomainhost (use the gedit text editor instead of kate if using Ubuntu instead of Kubuntu):

sudo kate /etc/apache2/sites-available/mydomainhost

and add the following lines to it:

#

<Location /WebDAV1>
 DAV On
 AuthType Basic
 AuthName "WebDAV1"
 AuthUserFile /var/www/WebDAV1/passwd.dav
 Require valid-user
</Location>

The final virtual host (vhost) file should resemble:

<VirtualHost *> # # UseCanonicalName off # ServerName WebDAV1.mydomain.org

ServerName myhost.mydomain.org
ServerAlias 192.168.0.155 WebDAV1.mydomain.org

#

ServerAdmin root@localhost
DocumentRoot /var/www/

#

Alias /WebDAV1 /var/www/WebDAV1/files

#

<Directory /var/www/WebDAV1/>
 Options Indexes MultiViews
 AllowOverride None
 Order allow,deny
 allow from all
</Directory>

#

<Location /WebDAV1>
 DAV On
 AuthType Basic
 AuthName "WebDAV1"
 AuthUserFile /var/www/WebDAV1/passwd.dav
 Require valid-user
</Location>

</VirtualHost>* Reload Apache:

/etc/init.d/apache2 reload

3.1.7 Testing WebDAV

  • Install cadaver, a command-line WebDAV client:

sudo apt-get install cadaver* Test if WebDAV works:

cadaver http://localhost/WebDAV1/

You should be prompted for a user name. Type in testuser and then the password for testuser. If all goes well, you should be granted access which means WebDAV is working ok. To leave the WebDAV shell, type quit:

server1:~# cadaver http://localhost/WebDAV1/ Authentication required for test on server `localhost': Username: testuser Password: ******* dav:/WebDAV1/> quit Connection to `localhost' closed. server1:~#

3.1.8 Set up Digest Authorization (encrypted passwords)

sudo a2enmod auth_digest* Create a digest authorization password file:

sudo htdigest -c /var/www/WebDAV1/digestpasswd.dav WebDAV1digest testuser* Add other users (e.g. testuser2, testuser3, etc.) as needed. (Omit the -c switch because the password file already exists.)

sudo htdigest /var/www/WebDAV1/digestpasswd.dav WebDAV1digest testuser2

Note: See below for adding a password for users accessing WebDAV folders from Windows clients. * Change the permissions of the /var/www/WebDAV1/digestpasswd.dav file so that only www-data (as owner) and user (or, alternatively, root) as the group can access it:

sudo chown www-data:user /var/www/WebDAV1/digestpasswd.dav sudo chmod 660 /var/www/WebDAV1/digestpasswd.dav

Note: I personally use chmod 460, which does not allow the www-data owner to write to the file (only read permissions are allowed). Only members of the local group user can read/write to the file using this chmod 460 setting. * Edit the virtual host (vhost) file /etc/apache2/sites-available/mydomainhost (use the gedit text editor instead of kate if using Ubuntu instead of Kubuntu):

sudo kate /etc/apache2/sites-available/mydomainhost

and this time add the following lines to it:

#

<Location /WebDAV1>
 DAV On
 AuthType Digest
 AuthName "WebDAV1digest"
 AuthUserFile /var/www/WebDAV1/digestpasswd.dav
 Require valid-user
</Location>

so that the final file resembles:

<VirtualHost *> # # UseCanonicalName off # ServerName WebDAV1.mydomain.org

ServerName myhost.mydomain.org
ServerAlias 192.168.0.155 WebDAV1.mydomain.org

#

ServerAdmin root@localhost
DocumentRoot /var/www/

#

Alias /WebDAV1 /var/www/WebDAV1/files

# <Directory /var/www/WebDAV1/>

  Options Indexes MultiViews
  AllowOverride None
  Order allow,deny
  allow from all
</Directory>

# # <Location /WebDAV1> # DAV On # AuthType Basic # AuthName "WebDAV1" # AuthUserFile /var/www/WebDAV1/passwd.dav # Require valid-user # </Location> #

<Location /WebDAV1>
 DAV On
 AuthType Digest
 AuthName "WebDAV1digest"
 AuthUserFile /var/www/WebDAV1/digestpasswd.dav
 Require valid-user
</Location>

</VirtualHost>

3.1.9 Enable WebDAV lock

Although optional, the lock database prevents multiple users from overwriting the same file simultaneously. * Create a global Apache2 configuration file (use the gedit text editor instead of kate if using Ubuntu instead of Kubuntu):

sudo kate /etc/apache2/conf.d/WebDAV

and add the single line:

DavLockDB /var/lock/apache2/DAVLock

It may be necessary to also add this line to the dav_fs configuration file:

sudo kate /etc/apache2/mods-available/dav_fs.conf

This directive indicates that the locking database files will be named DAVLock by the dav_lock module. These database files will be stored by Apache in the /var/lock/apache2 folder. * By default, Apache2 allows a WebDAV client to set the file lock time. Many WebDAV clients, for example, impose a file lock time of 2 minutes. A longer lock time can optionally be imposed by the WebDAV server by adding an additional line:

DAVMinTimeout 5

where in this example the minimum file lock time is set to 5 minutes for all clients. (The default is DAVMinTimeout 0, which indicates that no minimum file lock time is imposed by the server and it is left up to the individual WebDAV clients). * Enable the Apache2 dav_lock module:

sudo a2enmod dav_lock* Restart Apache2:

sudo /etc/init.d/apache2 restart

3.2 Multiple WebDAV servers on a LAN using a single IP address and router

Note: This section is undergoing editing. * To run multiple servers (including WebDAV servers) on multiple computers on a LAN using only a single IP address and router, see this solution using reverse proxies in Apache.

  • Each server should have a unique WebDAV folder name. Instead of using WebDAV1 and WebDAV1, different names, such as WebDAV2 and WebDAV2, WebDAV3 and WebDAV3, WebDAV4 and WebDAV4, etc., should be used on each of the individual computers.
  • Each computer's WebDAV folder would then be reached by its own unique label, e.g.

http://myhost.mydomain.org/WebDAV1

or

http://myhost.mydomain.org/WebDAV2

or

http://myhost.mydomain.org/WebDAV3

Alternatively, if each computer has its own unique URL, the unique URL can be used. Adjust the reverse proxy virtual host file (on the primary server that acts as the proxy/reverse proxy to the other servers) accordingly in order to enable this.

This does not always work and a lot of troubleshooting and trial and error is needed to perfect rewrite rules. Sometimes a more relaible method is to just use the RedirectMatch rule with the actual LAN IP address of the second server.

Here is a detailed example, although there are many ways to accomplish this. * On the primary server of the LAN (the one to which the router initially directs port 80 traffic), make sure the proxy/reverse proxy modules of Apache2 are enabled and then restart Apache:

sudo a2enmod proxy sudo a2enmod proxy_http sudo /etc/init.d/apache2 restart

Also makes sure the rewrite module is on:

sudo a2enmod rewrite* This example assumes the primary server has its own set of WebDAV folders (as in the steps outlined above), labeled WebDAV1/WebDAV1.

  • Duplicate the steps for the second server, substituting WebDAV2 and WebDAV2 in each step.
  • On the primary server, edit the virtual host file for the primary URL (e.g. /etc/apache2/sites-available/mydomainhost) by which the LAN is reached (use the gedit text editor instead of kate if using Ubuntu instead of Kubuntu):

sudo kate /etc/apache2/sites-available/mydomainhost* Near the beginning of the file add the lines:

#

UseCanonicalName off

#

RewriteEngine On
RedirectMatch (.*)/WebDAV2 http://192.168.0.156/WebDAV2

This example assumes, of course, that the second server is located on the LAN at IP address 192.168.0.156. This ensures that the newly transformed URL gets sent to the correct IP address on the LAN. This is the proxy function of the first server. (It also specifies the reverse process.)

The file should now resemble:

<VirtualHost *> #

UseCanonicalName off

#

RewriteEngine On
RedirectMatch (.*)/WebDAV2 http://192.168.0.156/WebDAV2

# # ServerName WebDAV1.mydomain.org

ServerName myhost.mydomain.org
ServerAlias 192.168.0.155 WebDAV1.mydomain.org

#

ServerAdmin root@localhost
DocumentRoot /var/www/

#

Alias /WebDAV1 /var/www/WebDAV1/files

# <Directory /var/www/WebDAV1/>

  Options Indexes MultiViews
  AllowOverride None
  Order allow,deny
  allow from all
</Directory>

# # <Location /WebDAV1> # DAV On # AuthType Basic # AuthName "WebDAV1" # AuthUserFile /var/www/WebDAV1/passwd.dav # Require valid-user # </Location> #

<Location /WebDAV1>
 DAV On
 AuthType Digest
 AuthName "WebDAV1digest"
 AuthUserFile /var/www/WebDAV1/digestpasswd.dav
 Require valid-user
</Location>

</VirtualHost>

While this method is not required, it allows the second WebDAV server to be accessed from another computer on the LAN either by http://myhost.mydomain.org/WebDAV2 or by http://WebDAV2.mydomain.org. Using this method, by editing only the virtual host file on the primary server (that acts as proxy), access to the secondary WebDAV server can be selectively restricted to the LAN only or can be enabled for complete access from the Internet at large.

3.3 WebDAV with LDAP

Note: This section is undergoing editing.

If an LDAP server exists already, you can use the Apache2 mod_authnz_ldap module.

Do you intend to place each person's website in a separate directory below the common DAV root? If so, you'll probably want to limit access to each directory to its specific user for security. An .htpasswd file in each directory is the easiest solution, but it's safer to put all the access rules in the global WebDAV configuration file located in the /etc/apache2/sites-enabled folder.

3.4 References

4 Einrichtung

Zunächst sucht man sich ein Verzeichnis, das den WebDAV-Baum beinhalten wird, z.B. /var/www/html. Anschließend legt man den Verzeichnisbaum an, also

mkdir /var/www/html/files cd /var/www/html/files mkdir user1 user2

Anschließend werden die Benutzer angelegt:

htpasswd -bc .htpasswd user1 pwd1 htpasswd -b user2 pwd2 htpasswd -b superuser pwd3

Die Datei kann natürlich an einem beliebigen Ort liegen, wo Apache Zugriff hat. Es ist sogar etwas sicherer, die Passwort-Datei außerhalb eines per HTTP zugreifbaren Verzeichnisses zu platzieren, so dass selbst im Falle eines Konfigurationsfehlers die Datei mit den Passwörtern nicht einfach heruntergeladen werden kann. In der Standardkonfiguration sollte aber Apache das herunterladen von Dateien, die mit ".ht" beginnen, gar nicht zulassen.

Nun muss noch der DAV-Zugriff konfiguriert werden: Dies kann irgendwo in der Apache-Konfiguration passieren, ich lege meist eine neue conf-Datei in /etc/httpd/conf.d an. Diese sieht in etwa wie folgt aus:

Alias /dav /var/www/html/files/ <Location /dav>

     DAV On
     SSLRequireSSL 
     # how to authenticate a user
     AuthType Basic
     AuthName "Webordner"
     AuthUserFile /var/www/html/files/.htpasswd
     require user superuser

</Location>

<Location /dav/user1>

     require user user1 superuser
     Options +Indexes

</Location>

<Location /dav/user2>

     require user user2 superuser
     Options +Indexes

</Location>

Da die Dateien in einem normalen Verzeichnis unterhalb des Webroot liegen, kann man noch ganz normal per HTTP ohne Authentifizierung und Verschlüsselung die Dateien herunterladen. Das ist natürlich nicht gewollt. Um das zu verhindern, legt man eine .htaccess in /var/www/html/files mit dem folgenden Inhalt:

Deny from All

Praxistipp: Solltet ihr trotz des obigen Eintrags noch auf die Dateien zugreifen können, beachtet Apache die .htaccess-Datei nicht. Ein Grund dafür kann z.B. darin liegen, dass für euren Virtual Host oder für einen Verzeichnisbaum "AllowOverride None" gesetzt ist bzw. "AuthConfig" nicht in der AllowOverride-Liste steht.

4.1 Zugriffsrechte

Das DAV-Modul läuft unter den Rechten des Apache-Benutzers. Entsprechend ist auch der Eigentümer von neu geschriebenen Dateien Apache. Dies kann sehr ärgerlich sein, wenn z.B. Skripte auf eine per WebDAV hochgeladene Datei zugreifen sollen. Eine Lösung dafür können ACLs mit default-Einträgen sein, so dass neue Dateien in dem Verzeichnis sowohl von Apache als auch von einem (oder mehreren) normalen Benutzer geschrieben werden können:

setfacl --set \ user::rwx,group::r-x,other:r-x,group:apachegroup:rwx,\

   default:user:myuser:rwx,default:group:myusergroup:r-x,default:group:apachegroup:rwx,default:other:r-x \

/var/www/html/files

In diesem Beispiel erhält der Benutzer myuser (Gruppe myusergroup) alle Rechte auf das Verzeichnis und standardmäßig auch auf alle neuen Dateien darin. Gleiches gilt für die Gruppe des apache (apachegroup). Natürlich müssen die Namen entsprechend angepasst werden.

Mir ist derzeit (August 2007) keine Software bekannt, die es erlauben würde, den Eigentümer hochgeladener Dateien entsprechend der Anmeldung zu ändern. Dies wäre für mich insbesondere für CGI-Skripte im Zusammenhang mit suexec interessant.

4.2 Creating passwords for Windows clients

Some Windows clients (including Windows Explorer in XP) append the URL of the WebDAV folder to the user name. For example, when a WebDAV request is made by testuser3 to the WebDAV server at http://myhost.mydomain.org/WebDAV1, Windows will send a request for access as myhost.mydomain.org\testuser3.

To accommodate this behavior, additional user accounts in the Windows format must be added to the password file on the WebDAV server. Note the extra \ . * If using Basic Authentication, add the user to the password file:

sudo htpasswd /var/www/WebDAV1/passwd.dav myhost.mydomain.org\\testuser* If using Digest Authentication, add the user to the password file:

sudo htdigest /var/www/WebDAV1/digestpasswd.dav WebDAV1digest myhost.mydomain.org\\testuser* Note: There is a bug in the Windows WebDAV redirector when used with Digest Authentication. (See this tutorial for more details.) A workaround entails mapping the WebDAV folder to a drive letter using the command line. This can only be done in a Windows computer that has just been booted.

  • Mount the WebDAV folder to a Windows drive letter with the Net use command. Enter the following into the Windows Start menu -> Run... command line:

net use * "http://myhost.mydomain.org/WebDAV1/" testuserpassword /user:myhost.mydomain.org\testuser* A specific drive letter (such as W:) can be used instead of the *. The * option specifies to mount the resource to the next available Windows drive letter.

  • To make the mapping permanent, add the option /persistent:yes
  • A (.bat) batch file can be created that contains this net use command. A Windows shortcut to this batch file can then be placed in the Windows Start menu -> Programs -> Start folder. This will run the net use command (from the batch file) at every bootup (following the start of all basic services). The batch file may need to address the net command by its absolute folder location:

C:\WINDOWS\system32\net use * "http://myhost.mydomain.org/WebDAV1/" testuserpassword /user:myhost.mydomain.org\testuser* To disconnect a web folder (either from the Start menu -> Run... dialog box or from a batch file, where X: is mounted Windows drive letter:

net use X: /delete

4.3 Apache Module mod_dav

Description: Distributed Authoring and Versioning (WebDAV) functionality
Status: Extension
Module Identifier: dav_module
Source File: mod_dav.c

4.3.1 Summary

This module provides class 1 and class 2 WebDAV ('Web-based Distributed Authoring and Versioning') functionality for Apache. This extension to the HTTP protocol allows creating, moving, copying, and deleting resources and collections on a remote web server.

4.3.2 Directives

4.3.3 Topics

4.3.4 See also

4.3.5 Enabling WebDAV

To enable mod_dav, add the following to a container in your httpd.conf file:

Dav O

This enables the DAV file system provider, which is implemented by the mod_dav_fs module. Therefore, that module must be compiled into the server or loaded at runtime using the LoadModule directive.

In addition, a location for the DAV lock database must be specified in the global section of your httpd.conf file using the DavLockDB directive:

DavLockDB /usr/local/apache2/var/DavLock

The directory containing the lock database file must be writable by the User and Group under which Apache is running.

You may wish to add a <Limit> clause inside the <Location> directive to limit access to DAV-enabled locations. If you want to set the maximum amount of bytes that a DAV client can send at one request, you have to use the LimitXMLRequestBody directive. The "normal" LimitRequestBody directive has no effect on DAV requests.

4.3.5.1 Full Example

DavLockDB /usr/local/apache2/var/DavLock
<Directory /usr/local/apache2/htdocs/foo>
   Require all granted
   Dav On
   AuthType Basic
   AuthName DAV
   AuthUserFile user.passwd
   <LimitExcept GET POST OPTIONS>
       Require user admin
   </LimitExcept>
</Directory>

4.3.6 Security Issues

  • Since DAV access methods allow remote clients to manipulate files on the server, you must take particular care to assure that your server is secure before enabling mod_dav.
  • Any location on the server where DAV is enabled should be protected by authentication.
  • The use of HTTP Basic Authentication is not recommended.
  • You should use at least HTTP Digest Authentication, which is provided by the mod_auth_digest module.
  • Nearly all WebDAV clients support this authentication method.
  • An alternative is Basic Authentication over an SSL enabled connection.
  • In order for mod_dav to manage files, it must be able to write to the directories and files under its control using the User and Group under which Apache is running.
  • New files created will also be owned by this User and Group.
  • For this reason, it is important to control access to this account.
  • The DAV repository is considered private to Apache; modifying files outside of Apache (for example using FTP or filesystem-level tools) should not be allowed.
  • mod_dav may be subject to various kinds of denial-of-service attacks.
  • The LimitXMLRequestBody directive can be used to limit the amount of memory consumed in parsing large DAV requests.
  • The DavDepthInfinity directive can be used to prevent PROPFIND requests on a very large repository from consuming large amounts of memory.
  • Another possible denial-of-service attack involves a client simply filling up all available disk space with many large files.
  • There is no direct way to prevent this in Apache, so you should avoid giving DAV access to untrusted users.

4.3.7 Complex Configurations

  • One common request is to use mod_dav to manipulate dynamic files (PHP scripts, CGI scripts, etc).
  • This is difficult because a GET request will always run the script, rather than downloading its contents.
  • One way to avoid this is to map two different URLs to the content, one of which will run the script, and one of which will allow it to be downloaded and manipulated with DAV.
Alias /phparea /home/gstein/php_files
Alias /php-source /home/gstein/php_files
<Location /php-source>
   DAV On
   ForceType text/plain
</Location>

With this setup, http://example.com/phparea can be used to access the output of the PHP scripts, and http://example.com/php-source can be used with a DAV client to manipulate them.

4.3.8 Dav Directive

Description: Enable WebDAV HTTP methods
Syntax: Dav On|Off|provider-name
Default: Dav Off
Context: directory
Status: Extension
Module: mod_dav

Use the Dav directive to enable the WebDAV HTTP methods for the given container:

<Location /foo>
   Dav On
</Location>
  • The value On is actually an alias for the default provider filesystem which is served by the mod_dav_fs module.
  • Note, that once you have DAV enabled for some location, it cannot be disabled for sublocations.
  • For a complete configuration example have a look at the section above.
  • Do not enable WebDAV until you have secured your server.
  • Otherwise everyone will be able to distribute files on your system.

4.3.9 DavDepthInfinity Directive

Description: Allow PROPFIND, Depth: Infinity requests
Syntax: DavDepthInfinity on|off
Default: DavDepthInfinity off
Context: server config, virtual host, directory
Status: Extension
Module: mod_dav

Use the DavDepthInfinity directive to allow the processing of PROPFIND requests containing the header 'Depth: Infinity'. Because this type of request could constitute a denial-of-service attack, by default it is not allowed.

4.3.10 DavMinTimeout Directive

Description: Minimum amount of time the server holds a lock on a DAV resource
Syntax: DavMinTimeout seconds
Default: DavMinTimeout 0
Context: server config, virtual host, directory
Status: Extension
Module: mod_dav
  • When a client requests a DAV resource lock, it can also specify a time when the lock will be automatically removed by the server.
  • This value is only a request, and the server can ignore it or inform the client of an arbitrary value.
  • Use the DavMinTimeout directive to specify, in seconds, the minimum lock timeout to return to a client.
  • Microsoft Web Folders defaults to a timeout of 120 seconds; the DavMinTimeout can override this to a higher value (like 600 seconds) to reduce the chance of the client losing the lock due to network latency.

4.3.10.1 Example

<Location /MSWord>
   DavMinTimeout 600
</Location>

4.3.11 Was ist ein Protokoll?

  • Ein Protokoll dient der Festlegung eines Übertragungsstandarts
  • Es ist eine vereinbarte Logik für die Datenübertragung (Inhalt, auch zeitlicher Ablauf)
  • Es ist eine Spezifikation über das Datenformat und auch dessen Bedeutung (Syntax/Semantik)

4.3.12 Was ist HTTP?

Im Grunde genommen handelt es sich beim World Wide Web um ein verteiltes Hypermedia-System, bei dem die Informationen in Form von Webseiten gespeichert werden, die über Weblinks (URI/URL) miteinander verbunden sind. Das Hypertext Transfer Protocol (HTTP) ist ein für diese Eigenschaft des Web erforderliches Verfahren, für den Zugriff auf nicht lokal gespeicherte Informationen. Es stellt ein recht einfaches, auf einer Client/Server Architektur basierendes und auf einem verlässlichen verbindungsorientierten Transportdienst aufbauendes Request/Response Protokoll dar.

4.3.13 Aufbau einer HTTP Ineraktion

Das Schema einer HTTP Interaktion sieht dabei folgendermaßen aus: * Verbindungsaufbau

  • (Aufbau einer TCP-Verbindung vom Client zum Server)
  • Request vom Client zum Server
  • (Auswahl einer Methode, zusätzliche Parameter zur Methode)
  • Response vom Server zum Client
  • (Resultat in Form eines Statuscodes, zusätzliche Parameter zum Resultat)
  • Verbindungsabbau
  • (ab HTTP1.1 kann die Verbindungen bestehenbleiben)

Da es sich bei den Nachrichtentypen Request und Response um zum RFC 822 konforme Nachrichten handelt, ist das Format beider Typen sehr einfach:

generic-message = start-line

             *message-header
             CRLF
             [message-body] 

start-line = request-line | status-line

Bei der start-line handelt es sich entweder um eine request-line (wenn die HTTP -Nachricht ein Request ist) oder um eine status-line (wenn die HTTP - Nachricht ein Response ist). Nach der start-line können null oder mehr Header-Felder folgen (Details zu den einzelnen Headertypen).

4.3.14 Funktionalität

Der Standardentwurf RFC 2518 führt eine Reihe neuer Konzepte ein, die bei HTTP vermisst wurden bzw. als nicht genügend für eine kooperative Dokumentenpflege befunden wurden:* Überschreibschutz für Dokumente (Ressourcen):

  • Bearbeiter können Dokumente "blockieren", um Kollisionen bei der Bearbeitung zu verhindern (Locking). Dabei sieht man "persistente Locks" vor, die keine ständige Netzverbindung erfordern.
  • Metadaten:
  • Dokumenten können Eigenschaften (Properties) zugeordnet werden. Das sind beliebige Metadaten (einfach ausgedrückt Daten über Daten), die Syntax nutzt dabei XML.
  • Namensraumverwaltung (Namespace management):
  • Will man ganze Verzeichnishierarchien bzw. Namensräume statt einzelne Dokumente manipulieren (löschen, verschieben etc.), so heißt das dazugehörende Konzept Collections.

Nicht im Standart RFC 2518 enthalten:* Ressourcen-Versionierung

  • Ressourcen-Suche
  • Zugriffskontrolle

WebDAV war ursprünglich für alle Punkte geplant, aufgrund des Umfangs wurden jedoch weitere Arbeitsgruppen gegründet:* DeltaV (Ressourcen-Versionierung)

  • DASL (Ressourcen-Suche)
  • ACL (Subarbeitsgruppe - Zugriffskontrolle)

4.4 WebDAV- Methoden

WebDAV setzt auf HTTP 1.1 (RFC 2616) auf und übernimmt von diesem alle Methoden für die Kommunikation, erweitert einige davon und fügt auch neue Methoden hinzu. Diese Methoden sind für die Gewährleistung der neuen Funktionalitäten (Lockig, Properties, Collections) notwendig.

4.4.1 HTTP selbst definiert acht Methoden

  • GET / PUT / DELETE
    • Eine Ressource anfordern, schreiben oder löschen
    • (WebDAV: DELETE Þ eine Collection löschen)
  • POST
    • Informationen an den Server Übermitteln (Formulardaten u.Ä.)
  • HEAD
    • Ähnlich wie GET. Unterschied liegt darin, dass der Server in seinem Response keinen Message Body zurückgeben muss.
  • OPTIONS
    • Information über eine Kommunikation anfordern, ohne eine Aktion auszuführen
  • TRACE
    • Für Test- und Diagnosezwecke (Request-/Responsekette prüfen)
  • CONNECT
    • Reserviert für das Tunneling bei Proxies

4.4.2 Weitere sieben Methoden von WebDAV:

  • LOCK
    • Setzt für den Überschreibschutz eine Sperre auf eine Collection oder Ressource
  • UNLOCK
    • Gibt eine gesperrte Collection oder Ressource wieder frei
  • PROPFIND
    • Liest Metadaten von Ressourcen oder Collections
  • PROPPATCH
    • Schreibt Metadaten von Ressourcen oder Collections
  • COPY
    • Kopiert Collections und Ressourcen innerhalb eines zusammenhängenden Namensraumes
  • MOVE
    • Verschiebt Collections und Ressourcen innerhalb eines zusammenhängenden Namensraumes
  • MKCOL
    • Erzeugt eine neue Collectio

4.5 WebDAV- Prinzip

Im Folgenden wird der grundlegende Ablauf bei der Bearbeitung einer Ressource beschrieben. Die einzelnen Konzepte, die hierbei Erwähnung finden, werden im kommenden Kapiteln ausführlich besprochen:

4.5.1 Standardablauf

  1. Ressource zum bearbeiten sperren
  2. Ressource zum bearbeiten anfordern
  3. Änderungen vornehmen
  4. Geänderte Ressource speichern
  5. Ressource freigeben

4.5.2 Was passiert

  1. Es wird über die Methode LOCK ein Locktoken angefordert. Wird die Ressource gerade nicht bearbeitet, wird der Locktoken geliefert.
  2. Mit dem Locktoken wird die Ressource mittels der Methode GET angefordert.
  3. Jetzt können Veränderungen mit einem beliebigen Programm z.B. Word 2000 durchgeführt werden.
  4. Der Locking-Mechanismus hat üblicherweise ein Timeout, so dass die Bearbeitung nicht länger als die definierte Zeit dauern darf.
  5. Mit dem Locktoken wird die Ressource zum speichern mittels der Methode PUT an den Server übermittelt.
  6. Ist der Locktoken nicht per Timeout ungültig geworden und hat der Inhaber die nötigen Schreibrechte, wird der Server die Ressource speichern und den Erfolg per Statuscode melden.
  7. Abschließend wird der Locktoken mit der Methode UNLOCK an den Server zurückgegeben. Die Ressource ist für die Bearbeitung durch andere Personen freigegeben.

4.6 WebDAV - Namensraumverwaltung

WebDAV ermöglicht den Benutzern, die Ressourcen einer Webseite in eine Hierarchie von Collections oder Ordnern zu organisieren, ähnlich wie dies der Fall mit den Dateien im traditionellen Dateisystem ist. Diese Organisation ist virtuell und existiert nur im Kontext von WebDAV, sie hat nichts mit der physikalischen Organisation von Ressourcen auf einem Webserver zu tun. Eine Collection wird bei WebDAV auch Namespace (Namensraum) genannt. Das kann ein Webserver oder ein bestimmtes Verzeichnis sein. Das Ziel von Collections ist, Operationen auf WebDAV Ressourcen im großen Umfang zu erlauben. Es ist nicht nur möglich einzelne Ressourcen zu erzeugen, verschieben, kopieren und zu löschen, sondern auch komplette Collections. Auf der Ebene des User Interfaces unterscheidet sich das Management der Collection- Ressourcen nicht von dem Management des Dateisystems, wie z.B. unter Windows Explorer.

Da das Konzept der Collections bei der Namensraumverwaltung den Kern darstellt, wird der Aufbau einer Collection im Folgenden noch näher beleuchtet:

Ein Namensraum entspricht dem HTTP-URI Schema und wird mit " / " abgeschlossen.

Für jede URL in der HTTP Hierarchie existiert eine Collection, die jene URL als ein Mitglied enthält. Die Wurzel bzw. top-level Collection des Namespaces ist von dieser Regel befreit.

Im RFC 2518 wird eine Collection als eine Ressource, deren Zustand aus einer Liste interner URI Mitglieder und einer Menge von Eigenschaften (Properties) besteht, definiert. Eine Mitglied- URI muss relativ zu der Basis URI der Collection sein. Dies bedeutet, dass eine Mitglied- URI einer Basis URI gleich ist, wobei noch ein Segment für Non- Collection- Ressourcen oder ein Segment mit abschließenden "/" für Collection- Ressourcen hinzukommt.

4.6.1 Beispiel

Gibt es WebDAV Ressourcen A und B mit den URI’s U und V, einem zu V relativen U, so ist B eine Collection, die U als eine (interne) Mitglied- URI enthält. Sind also die Ressource mit der URL http://foo.com/bar/blah und die Ressource mit der URL http://foo.com/bar/ WebDAV tauglich, dann ist die Ressource mit der URL http://foo.com/bar/ eine Collection und enthält die URL http://foo.com/bar/blah als ein (internes) Mitglied.

4.6.2 Methoden zur Namensraumverwaltung

4.6.2.1 MKCOL

erzeugt eine neue Collection an dem durch die Request-URI spezifizierten Ort.Dabei muss die Hierarchie der Ressourcen beachtet werden. Erzeugt die MKCOL Methode eine neue Collection Ressource, so müssen alle Vorfahren vorhanden sein, ansonsten wird der Status Code 409 (Conflict) zurückgeliefert, z.B.:

Existieren bei einer zur Erzeugung einer Collection /a/b/c/d/ gestellten Request, weder /a/b/ noch /a/b/c/ so wird die Methode versagen.

Wurde eine Collection erfolgreich erzeugt, so wird als Response der Status 201 (Created) zurückgeliefert.

4.6.2.1.1 Beispiel

Dieses Beispiel erzeugt eine Collection /webdisc/xfiles/ auf dem Server www.server.org.

(Bei Fragen zum generellen Aufbau von Requests oder Responses siehe Kapitel Aufbau einer HTTP Interaktion)

4.6.2.1.1.1 >>Request

MKCOL /webdisc/xfiles/ HTTP/1.1 Host: www.server.org

4.6.2.1.1.2 >>Response

HTTP/1.1 201 Created

4.6.2.2 COPY

Die Anwendung der Copy Methode bezüglich einer Collection in Verbindung mit dem Depth Header mit dem Wert "infinity" bedeutet, dass die Collection Ressource inklusive aller internen Mitglieder (identifiziert durch die Request-URI) an den Ort, der im Destination Header durch die angegebene URI spezifiziert wird, kopiert werden soll. Die Mitglieder der Collection werden dabei entsprechend der Hierarchie kopiert (relativ zur Basis Collection).

Beim Kopieren einer Collection mit "Depth:0" Header, werden nur die Collection und deren Eigenschaften, nicht aber die Mitglieder- URI’s der Collection kopiert.

Wurde eine Collection erfolgreich kopiert, so wird als Response der Status 201 (Created) zurückgeliefert.

4.6.2.2.1 Beispiel
4.6.2.2.1.1 Request

COPY /container/ HTTP/1.1 Host: www.foo.bar Destination: http://www.foo.bar/othercontainer/ Depth: infinity Content-Type: text/xml; charset="utf-8" Content-Length: xxxx

     <?xml version="1.0" encoding="utf-8" ?>
     <d:propertybehavior xmlns:d="DAV:">
       <d:keepalive>*</d:keepalive>
     </d:propertybehavior>

Dieses Beispiel kopiert die Collection /container/ an den Ort, der im Destination Header angegeben ist (hier: http://www.foo.bar/othercontainer/). Die Mitglieder der Collection werden auch kopiert, da der Depth Header den Wert "infinity" besitzt.

Das Header-Feld Content-Type gibt den Medientyp des enthaltenen Entity an. Content-Length wird verwendet, um die Größe des Message Body in einer dezimalen Anzahl von Octets anzugeben.

Anschließend folgt der Message Body beginnend mit einer Processing Instruction, welche die Spezifikation der XML-Version enthält.

Propertybehavior ist ein XML-Element, das die Handhabung der Properties während der Ausführung von COPY oder MOVE beschreibt.

Keepalive mit dem Wert "*" bedeutet dabei, dass alle "live properties" der (Quell) Ressource auch am Bestimmungsort weiter existieren müssen.

4.6.2.2.1.2 >>Response

HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx

     <?xml version="1.0" encoding="utf-8" ?>
     <d:multistatus xmlns:d="DAV:">
       <d:response>
               <d:href>http://www.foo.bar/othercontainer/R2/</D:HREF>
               <d:status>HTTP/1.1 412 Precondition Failed</d:status>
       </d:response>
     </d:multistatus>

Es handelt sich hier um eine Response mit dem Statuscode 207 (Multi-Status). Dies bedeutet, dass das Entity ein XML multistatus Element enthält, welches eine Menge von XML Response Elementen mit den Serienstatuscodes 200, 300, 400, 500 beinhalten kann.

Im Beispiel wurden die meisten Ressourcen erfolgreich kopiert, bis auf die Collection R2. Hier gab es ein Problem (Fehlermeldung: 412 Precondition Failed) , so dass auch keine Mitglieder dieser Collection kopiert werden konnten.

4.6.2.3 MOVE

Die Anwendung der MOVE Methode bezüglich einer Collection in Verbindung mit dem Depth Header mit dem Wert "infinity" bedeutet, dass die Collection Ressource inklusive aller internen Mitglieder (identifiziert durch die Request-URI) an den Ort, der im Destination Header durch die angegebene URI spezifiziert wird, verschoben werden soll.

Nach der Anwendung der MOVE Methode, muss diese sowohl an der Quelle als auch am Bestimmungsort ein konsistentes Namespace geschaffen haben.

4.6.2.3.1 Beispiel
4.6.2.3.1.1 >>Request

MOVE /container/ HTTP/1.1 Host: www.foo.bar Destination: http://www.foo.bar/othercontainer/ Overwrite: F If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>) (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>) Content-Type: text/xml; charset="utf-8" Content-Length: xxxx

     <?xml version="1.0" encoding="utf-8" ?>
     <d:propertybehavior xmlns:d='DAV:'> 
        <d:keepalive>*</d:keepalive> 
     </d:propertybehavior> 
4.6.2.3.1.2 >>Response

HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx

     <?xml version="1.0" encoding="utf-8" ?>
      <d:multistatus xmlns:d='DAV:'>
        <d:response>
           <d:href>http://www.foo.bar/othercontainer/C2/</d:href>
           <d:status>HTTP/1.1 423 Locked</d:status>
        </d:response>
      </d:multistatus>

Dieses Beispiel ähnelt sehr dem von der COPY Methode mit dem Unterschied, dass hier der Client mit der Request eine Anzahl von Locktokens (Schlossmarken) eingereicht hat. Dies wird in dem If Header realisiert. Es müssen für jede Ressource, sowohl für die Quelle als auch für den Bestimmungsort Locktokens eingereicht werden.

Im Beispiel wurde für den Bestimmungsort http://www.foo.bar/othercontainer/C2/ ein falscher Locktoken (Fehlermeldung: 423 Locked) eingereicht, was bedeutet, dass die Ressource /container/C2/ nicht verschoben werden konnte.

4.7 WebDAV- Überschreibschutz

Der Locking- Mechanismus ist für die Gewährleistung der Datenkonsistenz erforderlich. Clients werden damit daran gehindert, simultan auf die gleiche Ressource zuzugreifen. Mit Hilfe von Locks (write locks) wird also sichergestellt, dass kein Client eine sich bereits in Bearbeitung befindende Ressource abändern wird. Mit dieser Maßnahme kann das sogenannte "Lost Update" Problem verhindert werden.

Locks können sowohl auf einzelne Ressourcen, als auch auf ganze Collections gesetzt werden.

Man unterscheidet dabei shared und exclusive Locks:

4.7.1 Shared locking

Mehrere Benutzer können die Ressource bearbeiten. Wurde von einem Benutzer ein Lock gesetzt, so wird ein anderer Benutzer, der die gleiche Ressource ebenfalls bearbeiten möchte, gewarnt und darüber informiert, wer gerade an der Bearbeitung beteiligt ist. Der gewarnte Benutzer kann dann entscheiden, ob er diese Ressource trotzdem bearbeiten möchte.

4.7.2 Exclusive locking

Hierbei kann nur ein Benutzer die Ressource bearbeiten. Wurde ein Dokument also gesperrt, so kann kein anderer Benutzer dieses verändern.

Der Locking- Mechanismus betrifft bei WebDAV nur den Schreibzugriff. Der Lesezugriff auf eine Ressource ist immer möglich. Es besteht jeder Zeit die Möglichkeit, Informationen über den Eigentümer des jeweiligen Locks zu bekommen (lock discovery).

Bei dem Locking-Konzept spielen Locktoken eine wesentliche Rolle. Ein Locktoken wird bei jeder erfolgreichen LOCK Operation zurückgeliefert. Diese werden als URI‘s dargestellt, die ein spezielles Lock identifizieren. Sie müssen über alle Ressourcen und jeder Zeit eindeutig sein (opaquelocktoken URI Schema).

4.7.3 Methoden des Locking-Mechanismus

4.7.4 LOCK

Der Aufruf dieser Methode erzeugt ein Lock auf die durch die Request-URI angegebene Ressource. Das lockinfo XML Element spezifiziert dabei den Lock. Eine Lock- Method- Request sollte außerdem ein XML Request Body beinhalten, welches ein owner XML Element für diese Lock Request enthält. Zudem sollte ein Timeout Header vorhanden sein. Der Response muss den Wert der lockdiscovery property im prop XML Element enthalten.

4.7.4.1 Beispiel

4.7.4.1.1 >>Request

LOCK /workspace/WebDAV/proposal.doc HTTP/1.1 Host: WebDAV.sb.aol.com Timeout: Infinite, Second-4100000000 Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Authorization: Digest username="ejw", realm="ejw@WebDAV.sb.aol.com", nonce="...", uri="/workspace/WebDAV/proposal.doc", response="...", opaque="..."

  <?xml version="1.0" encoding="utf-8" ?>
  <D:lockinfo xmlns:D='DAV:'>
    <D:lockscope><D:exclusive/></D:lockscope>
    <D:locktype><D:write/></D:locktype>
    <D:owner>
         <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:HREF>
    </D:owner>
  </D:lockinfo>
4.7.4.1.2 >>Response

HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx

  <?xml version="1.0" encoding="utf-8" ?>
  <D:prop xmlns:D="DAV:">
    <D:lockdiscovery>
         <D:activelock>
              <D:locktype><D:write/></D:locktype>
              <D:lockscope><D:exclusive/></D:lockscope>
              <D:depth>Infinity</D:depth>
                     <D:owner>
                      <D:href>
                        http://www.ics.uci.edu/~ejw/contact.html
                      </D:href>
               </D:owner>
              <D:timeout>Second-604800</D:timeout>
              <D:locktoken>
                   <D:href>
                      opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
                   </D:href>
              </D:locktoken>
         </D:activelock>
    </D:lockdiscovery>
  </D:prop>

Das Beispiel zeigt eine erfolgreiche Erzeugung eines exclusive write Locks bezüglich der Ressource http://WebDAV.sb.aol.com/workspace/WebDAV/proposal.doc. Die Ressource http://www.ics.uci.edu/~ejw/contact.html enthält Kontaktinformationen des lock Besitzers (owner).

Das prop XML Element ist ein Container für die bezüglich einer Ressource definierten properties. Lockdiscovery ist eine Propertie, die den Lockbesitzer, Locktyp, Timeouttyp und den Lock enthält.

Der Response enthält ein Timeout von 604800, was bedeutet, dass der Lock automatisch nach 1 Woche wieder gelöscht wird.

4.7.5 UNLOCK

Die UNLOCK Methode entfernt ein Lock von der durch die Request- URI bezeichneten Ressource (inklusive aller noch durch das Lock gesperrten Ressourcen). Dieses Lock wird durch ein Lock Token des Request Headers identifiziert.

Kann eine der durch das Lock gesperrten Ressourcen nicht wieder freigegeben werden, so muss das UNLOCK Request versagen.

4.7.5.1 Beispiel

4.7.5.1.1 >>Request

UNLOCK /workspace/WebDAV/info.doc HTTP/1.1 Host: WebDAV.sb.aol.com Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7> Authorization: Digest username="ejw", realm="ejw@WebDAV.sb.aol.com", nonce="...", uri="/workspace/WebDAV/proposal.doc", response="...", opaque="..."

4.7.5.1.2 >>Response

HTTP/1.1 204 No Content

In diesem Beispiel wird der durch den Lock Token "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" identifiziertes Lock von der Ressource http://WebDAV.sb.aol.com/workspace/WebDAV/info.doc erfolgreich entfernt.

4.8 WebDAV- Metadaten

Im Folgenden wird das Konzept der Properties bzw. Metadaten (Informationen über Informationen) bei WebDAV erläutert:

Properties beschreiben den Zustand einer Ressource, wie z.B. die Länge eines Dokuments oder den Autor. Sie spielen eine grosse Rolle bei der "Discovery" oder beim Ressourcen Management. So kann z.B. später festgestellt werden, welcher Autor welches Dokument verfaßt hat.

Das WebDAV property Modell besteht aus name/value Paaren. Bei den Namen handelt es sich um Strings und bei den Werten um XML Ausdrücke.

Die Benutzung von XML hat den Vorteil, dass abhängig von der Applikation die Properties zwischen einfachen und komplexen Ausdrücken variieren können.

Da XML den Unicode unterstützt, können Properties in den meisten Sprachen ausgedrückt werden.

WebDAV legt keine Restriktionen bezüglich des Formats der Properties fest. Es können etwaige XML- basierende Standards benutzt werden. Einige besser bekannte Standards für Metadaten sind: Dublin Core, PICS usw.

Es existieren zwei Kategorien von Properties: "live" und "dead". Diese unterscheiden sich in ihrem Verhalten beim Kopieren oder Verschieben von Ressourcen.

Die beiden bezüglich Properties wichtigen Methoden sind:

4.8.1 PROPFIND

Liest die Properties der durch die Request- URI spezifizierten Ressource. Der Client spezifiziert im Body des Requests durch das propfind XML Element die Informationen, nach denen er sucht. Es ist möglich nach einem speziellen Wert, allen property Werten oder Liste von Namen der Properties einer Ressource zu fragen. Der Client hat auch die Möglichkeit keinen Body einzubinden. Im diesem Falle wird der Request als eine Frage nach Namen und Werten aller Properties behandelt.

4.8.1.1 Beispiel

4.8.1.1.1 >>Request

PROPFIND /file HTTP/1.1 Host: www.foo.bar Content-type: text/xml; charset="utf-8" Content-Length: xxxx

  <?xml version="1.0" encoding="utf-8" ?>
  <D:propfind xmlns:D="DAV:">
    <D:prop xmlns:R="http://www.foo.bar/boxschema/">
         <R:bigbox/>
         <R:author/>
         <R:DingALing/>
         <R:Random/>
    </D:prop>
  </D:propfind>
4.8.1.1.2 >>Response

HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx

  <?xml version="1.0" encoding="utf-8" ?>
  <D:multistatus xmlns:D="DAV:">
    <D:response>
         <D:href>http://www.foo.bar/file</D:HREF>
         <D:propstat>
              <D:prop xmlns:R="http://www.foo.bar/boxschema/">
                   <R:bigbox>
                        <R:BoxType>Box type A</R:BoxType>
                   </R:bigbox>
                   <R:author>
                        <R:Name>J.J. Johnson</R:Name>
                   </R:author>
              </D:prop>
              <D:status>HTTP/1.1 200 OK</D:status>
         </D:propstat>
         <D:propstat>
              <D:prop><R:DingALing/><R:Random/></D:prop>
                      <D:status>HTTP/1.1 403 Forbidden</D:status>                  
           <D:responsedescription> The user does not have access to
                                         the DingALing property.
           </D:responsedescription>
         </D:propstat>
    </D:response>
    <D:responsedescription> There has been an access violation error.
    </D:responsedescription>
  </D:multistatus>

Im Beispiel wird die PROPFIND Methode auf die Ressource http://www.foo.bar/file (die keine Collection ist) angewendet. Der propfind XML Element spezifiziert die Namen von vier Properties, nach deren Werten gefragt wird.

Der Response liefert nur zwei der vier gefragten Properties, da der Benutzer nicht genügend Zugriffsrechte bezüglich der DingALing und Random Property besitzt.

4.8.2 PROPPATCH

Schreibt und entfernt die Properties der durch die Request- URI spezifizierten Ressource.Der Request Message Body muss den propertyupdate XML Element enthalten. Dieses Element ist ein Container, welcher die zur Veränderung der Properties notwendigen Information enthält.

4.8.2.1 Beispiel

4.8.2.1.1 >>Request

PROPPATCH /bar.html HTTP/1.1 Host: www.foo.com Content-Type: text/xml; charset="utf-8" Content-Length: xxxx

  <?xml version="1.0" encoding="utf-8" ?>
  <D:propertyupdate xmlns:D="DAV:"
  xmlns:Z="http://www.w3.com/standards/z39.50/">
    <D:set>
         <D:prop>
              <Z:authors>
                   <Z:Author>Jim Whitehead</Z:Author>
                   <Z:Author>Roy Fielding</Z:Author>
              </Z:authors>
         </D:prop>
    </D:set>
    <D:remove>
         <D:prop><Z:Copyright-Owner/></D:prop>
    </D:remove>
  </D:propertyupdate>
4.8.2.1.2 >>Response

HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx

  <?xml version="1.0" encoding="utf-8" ?>
  <D:multistatus xmlns:D="DAV:"
  xmlns:Z="http://www.w3.com/standards/z39.50">
    <D:response>
         <D:href>http://www.foo.com/bar.html</D:HREF>
         <D:propstat>
              <D:prop><Z:Authors/></D:prop>
              <D:status>HTTP/1.1 424 Failed Dependency</D:status>
         </D:propstat>
         <D:propstat>
              <D:prop><Z:Copyright-Owner/></D:prop>
              <D:status>HTTP/1.1 409 Conflict</D:status>
         </D:propstat>
         <D:responsedescription> Copyright Owner can not be deleted or
  altered.</D:responsedescription>
    </D:response>
  </D:multistatus>

In diesem Beispiel veranlasst der Client den Server, den Wert der http://www.w3.com/standards/z39.50/Authors Property zu setzten und die http://www.w3.com/standards/z39.50/Copyright- Owner Property zu entfernen.

Das set XML Element beinhaltet dabei die Werte, die gesetzt werden sollen, remove die Property, die entfernt werden soll. Solange die Copyright-Owner property nicht entfernt werden kann, werden keine Abänderungen an den Properties durchgeführt. Der 424 (Failed Dependency) Status Code bedeutet, dass die Aktion bezüglich der Autoren geglückt wäre, wenn es kein Konflikt mit dem Entfernen der Copyright-Owner property gegeben hätte.

4.8.2.2 Vordefinierte Properties

  • creationdate
  • displayname
  • getcontentlanguage
  • getcontentlength
  • getetag
  • getlastmodified
  • lockdiscovery
  • resourcetype
  • source
  • supportedlock

5 Weiter Informationen

5.1

    • RFC 2291 – Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web
    • RFC 2518 – HTTP Extensions for Distributed Authoring – WebDAV
    • RFC 3253 – Versioning Extensions to WebDAV
    • RFC 3648 – Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol
    • RFC 3744 – Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol
    • RFC 4316 – Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties
    • RFC 4331 – Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections
    • RFC 4437 – Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources
    • RFC 4918 – HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
    • RFC 5323 – Web Distributed Authoring and Versioning (WebDAV) SEARCH
    • RFC 6578 – Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV)

5.2 Weblinks

5.3 Software Links

5.4 WebDAV-Anbieter

Es gibt eine Reihe von Anbietern, die Zugang zu Webspace zum Teil sogar kostenlos anbieten. Hier sollen Anbieter und die Zugangsdaten gesammelt werden.

Anbieter
Anbietername Dienste-Typ Server Ordner Benutzername
GMX Mediacenter Sicheres WebDAV (HTTPS) https://WebDAV.mc.gmx.net leer lassen Kundennummer bzw. gmx-E-Mail-Adresse
WEB.DE Smartdrive Sicheres WebDAV (HTTPS) https://WebDAV.smartdrive.web.de leer lassen web.de-Benutzername
ownCloud Sicheres WebDAV (HTTPS) https://ownCloud-SERVER-URL/remote.php/WebDAV/ / owncloud Benutzername
T-Online Sicheres WebDAV (HTTPS) https://WebDAV.mediencenter.t-online.de / T-Online-E-Mail-Adresse
1&1 SmartDrive (DSL Kunden) Sicheres WebDAV (HTTPS) https://sd2dav.1und1.de / E-Mail-Adresse
1&1 SmartDrive (Webhosting Kunden) Sicheres WebDAV (HTTPS) https://WebDAV.office.1und1.de/ / E-Mail-Adresse
Domainfactory Sicheres WebDAV (HTTPS) FTPUSERNAME.livedisk.df.eu/WebDAV/ / FTPUSERNAME@web.dav
freenet Sicheres WebDAV (HTTPS) https://storage.freenet.de/dav / freenet-Nutzerdaten
myDisk.se Sicheres WebDAV (HTTPS) https://mydisk.se/Benutzername / freie Eingabe
Humyo.com (nicht empfehlenswert, buggy!) Sicheres WebDAV (HTTPS) https://dav.humyo.com / E-Mail-Adresse
mydrive.ch Sicheres WebDAV (HTTPS) https://WebDAV.mydrive.ch / Benutzername
Strato Hidrive Sicheres WebDAV (HTTPS) https://WebDAV.hidrive.strato.com/ (s. Anleitung) Benutzername
UD Media Sicheres WebDAV (HTTPS) https://<user>.WebDAV.<server>/ / Benutzername

5.4.1 Hinweis

Nutzer der 1&1-Webpakete: Hier muss hinter der URL immer noch der Port 81 angegeben werden, also z.B.

# WebDAV bei 1&1 http://meinWebDAV.domain.de:81 /home/user/mnt/1und1 davfs user,noauto 0 0

WebDAV - Einrichtung unter Windows 7#

Grafik1.png

Öffnen Sie den Windows-Explorer und klicken Sie mit rechter Maustaste auf Computer. Wählen Sie Netzlaufwerk verbinden.

  1. Es öffnet sich eine Eingabeaufforderung. Wählen Sie einen freien Laufwerksbuchstaben und tragen Sie hier bitte den Pfad zum WebDAV-Server ein.
  2. Tragen Sie bitte https:// als Präfix ein.
  3. Serverpfad
  4. https://WebDAV.h2t.eu (SSL-verschlüsselter Verbindungsaufbau)

Datei:Grafik2.png

Sie werden aufgefordert Kontonamen sowie das von Ihnen vergebene Passwort einzutragen.

  1. Die Freigabe Konto ist unter dem gewählten Laufwerksbuchstaben im Windows-Explorer eingebunden und kann wie eine gewöhnliche Festplatte genutzt werden.
  2. Datei:Grafik4.png
  1. Langsamen Verbindungsaufbau beheben

Sofern die Zugriffe auf Ordner nur sehr langsam möglich sind, kann dies an den voreingestellten Netzwerkeinstellungen von Windows liegen.

  1. Rufen Sie die Systemsteuerung von Windows auf. Klicken Sie bei den Internetoptionen auf Verbindungen und LAN-Einstellungen. Deaktivieren Sie die Option Automatische Suche der Einstellungen.