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.
Enable the Apache2 WebDAV modules
Enable the dav and dav_fs modules:
# a2enmod dav_fs
Restart Apache2
# systemctl restart apache2
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
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.
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. *
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.):
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.)
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:
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
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:~#
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:
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
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:
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.
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/
* 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:
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.
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.
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 Kryptografie 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.
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:
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.
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:
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:
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:
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.
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.
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>
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.
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>
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.
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.
Example
<Location /MSWord>
DavMinTimeout 600
</Location>
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)
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.
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:
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).
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)
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.
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
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
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:
Standardablauf
Ressource zum bearbeiten sperren
Ressource zum bearbeiten anfordern
Änderungen vornehmen
Geänderte Ressource speichern
Ressource freigeben
Was passiert
Es wird über die Methode LOCK ein Locktoken angefordert. Wird die Ressource gerade nicht bearbeitet, wird der Locktoken geliefert.
Mit dem Locktoken wird die Ressource mittels der Methode GET angefordert.
Jetzt können Veränderungen mit einem beliebigen Programm z.B. Word 2000 durchgeführt werden.
Der Locking-Mechanismus hat üblicherweise ein Timeout, so dass die Bearbeitung nicht länger als die definierte Zeit dauern darf.
Mit dem Locktoken wird die Ressource zum speichern mittels der Methode PUT an den Server übermittelt.
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.
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.
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.
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.
Methoden zur Namensraumverwaltung
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.
Beispiel
Dieses Beispiel erzeugt eine Collection /webdisc/xfiles/ auf dem Server www.server.org.
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.
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.
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.
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.
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.
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:
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.
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).
Methoden des Locking-Mechanismus
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.
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.
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.
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.
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:
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.
<?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.
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.
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.
Vordefinierte Properties
creationdate
displayname
getcontentlanguage
getcontentlength
getetag
getlastmodified
lockdiscovery
resourcetype
source
supportedlock
Weiter Informationen
RFCs
RFC 2291 – Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web
RFC 2518 – HTTP Extensions for Distributed Authoring – WebDAV
Es gibt eine Reihe von Anbietern, die Zugang zu Webspace zum Teil sogar kostenlos anbieten. Hier sollen Anbieter und die Zugangsdaten gesammelt werden.
Sie werden aufgefordert Kontonamen sowie das von Ihnen vergebene Passwort einzutragen.
Die Freigabe Konto ist unter dem gewählten Laufwerksbuchstaben im Windows-Explorer eingebunden und kann wie eine gewöhnliche Festplatte genutzt werden.
Sofern die Zugriffe auf Ordner nur sehr langsam möglich sind, kann dies an den voreingestellten Netzwerkeinstellungen von Windows liegen.
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.
TMP
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.
