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:
Nicht im Standart RFC 2518 enthalten:
WebDav war ursprünglich für alle Punkte geplant, aufgrund des Umfangs wurden jedoch weitere Arbeitsgruppen gegründet:
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:
Weitere sieben Methoden von WebDav:
Standardablauf:
Was passiert:
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.
Im Folgenden soll ein Überblick über die wesentlichen Methoden zur Namensraumverwaltung gegeben werden:
· 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.
(Bei Fragen zum generellen Aufbau von Requests oder Responses siehe Kapitel
Aufbau einer HTTP Interaktion)
>>Request
MKCOL /webdisc/xfiles/ HTTP/1.1
Host: www.server.org
>>Response
HTTP/1.1 201 Created
· 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.
Beispiel:
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.
>>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.
Beispiel:
>>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>
>>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.
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.
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).
Die beiden wichtigen Methoden, die das Konzept des Locking-Mechanismus realisieren, sind:
· LOCK:Beispiel:
>>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>
>>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.
Beispiel:
>>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="..."
>>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.
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.
Beispiel:
>>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>
>>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.
·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.
Beispiel:
>>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>
>>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.
Einige im WebDav vordefinierte Properties:
· creationdate
· displayname
· getcontentlanguage
· getcontentlength
· getetag
· getlastmodified
· lockdiscovery
· resourcetype
· source
· supportedlock
... [ Seminar Linux und Apache ]...
[ WebDav ]... [ Die Funktionalität des WebDavs ]...
[ WebDav in der Praxis ] ...