Zum Hauptinhalt springen

RFC 4918 - HTTP-Erweiterungen: Web Distributed Authoring and Versioning (WebDAV)

  • Status: Proposed Standard
  • Veröffentlicht: June 2007
  • Stream: IETF
  • Ersetzt: RFC2518
  • Errata: Keine Errata

Zusammenfassung (Abstract)​

Web Distributed Authoring and Versioning (WebDAV) besteht aus einer Reihe von Methoden, Headern und Content-Types, die HTTP/1.1 ergänzen und zur Verwaltung von Ressourceneigenschaften (Resource Properties), zur Erstellung und Verwaltung von Ressourcensammlungen (Resource Collections), zur Manipulation des URL-Namespace (URL Namespace Manipulation) und zur Ressourcensperre (Resource Locking, zur Konfliktvermeidung) dienen.

RFC 2518 wurde im Februar 1999 veröffentlicht. Diese Spezifikation ersetzt RFC 2518 mit geringfügigen Überarbeitungen, die auf Interoperabilitätserfahrungen basieren.

Status dieses Memorandums (Status of This Memo)​

Dieses Dokument spezifiziert ein Internet-Standards-Track-Protokoll für die Internet-Community und fordert Diskussion und Vorschläge zur Verbesserung auf. Bitte beziehen Sie sich auf die aktuelle Ausgabe der "Internet Official Protocol Standards" (STD 1) für den Standardisierungsstatus und Status dieses Protokolls. Die Verteilung dieses Memorandums ist unbegrenzt.

Copyright (C) The IETF Trust (2007).

Inhaltsverzeichnis (Contents)​

Hauptabschnitte​

Anhänge (Appendices)​

Kernkonzepte von WebDAV​

Hauptfunktionen​

WebDAV erweitert das HTTP/1.1-Protokoll mit den folgenden Kernfunktionen:

  1. Eigenschaften (Properties): Metadaten für Web-Ressourcen hinzufügen, ändern und abfragen
  2. Sammlungen (Collections): Hierarchische Strukturen von Ressourcen erstellen und verwalten
  3. Sperren (Locking): Konflikte bei gleichzeitiger Bearbeitung verhindern, unterstützt exklusive und gemeinsame Sperren
  4. Namespace-Operationen: Web-Ressourcen kopieren und verschieben

Neue HTTP-Methoden​

  • PROPFIND: Eigenschaften einer Ressource abrufen
  • PROPPATCH: Eigenschaften einer Ressource ändern
  • MKCOL: Eine Sammlung erstellen (ähnlich dem Erstellen eines Verzeichnisses)
  • COPY: Eine Ressource oder Sammlung kopieren
  • MOVE: Eine Ressource oder Sammlung verschieben oder umbenennen
  • LOCK: Eine Ressource sperren, um Konflikte zu vermeiden
  • UNLOCK: Eine Ressource entsperren

Neue HTTP-Statuscodes​

  • 207 Multi-Status: Multi-Status-Antwort für Stapeloperationen
  • 422 Unprocessable Entity: Die Anfrage war wohlgeformt, enthielt aber semantische Fehler
  • 423 Locked: Die Ressource ist gesperrt
  • 424 Failed Dependency: Die Anfrage schlug aufgrund des Scheiterns einer vorherigen Anfrage fehl
  • 507 Insufficient Storage: Unzureichender Speicher zum Abschließen der Anfrage

Anwendungsfälle​

  • Kollaborative Bearbeitung: Mehrere Benutzer bearbeiten gleichzeitig Web-Inhalte
  • Content-Management-Systeme (CMS): Fernverwaltung von Website-Inhalten
  • Dateifreigabe: Datei-Upload und -Download über HTTP-Protokoll
  • Cloud-Speicher: Implementierung von HTTP-basierten Dateispeicherdiensten

1. Einführung (Introduction)​

Dieses Dokument beschreibt eine Erweiterung des HTTP/1.1-Protokolls, die es Clients ermöglicht, remote Web-Content-Authoring-Operationen durchzuführen. Diese Erweiterung bietet eine kohärente Menge von Methoden, Headern, Request-Entity-Body-Formaten und Response-Entity-Body-Formaten, die Operationen für Folgendes bereitstellen:

Eigenschaften (Properties): Die Fähigkeit, Informationen über Webseiten zu erstellen, zu entfernen und abzufragen, wie z.B. ihre Autoren, Erstellungsdaten usw.

Sammlungen (Collections): Die Fähigkeit, Dokumentenmengen zu erstellen und eine hierarchische Mitgliedschaftsliste abzurufen (wie eine Verzeichnisliste in einem Dateisystem).

Sperren (Locking): Die Fähigkeit zu verhindern, dass mehrere Personen gleichzeitig an einem Dokument arbeiten. Dies verhindert das „Problem des verlorenen Updates (Lost Update Problem)", bei dem Änderungen verloren gehen, wenn zuerst ein Autor und dann ein anderer Änderungen schreibt, ohne die Änderungen des anderen Autors zu fusionieren.

Namespace-Operationen (Namespace Operations): Die Fähigkeit, den Server anzuweisen, Web-Ressourcen zu kopieren und zu verschieben, Operationen, die die Zuordnung von URLs zu Ressourcen ändern.

Die Anforderungen und die Begründung für diese Operationen werden in einem Begleitdokument beschrieben, „Anforderungen für ein Protokoll für verteiltes Authoring und Versionierung für das World Wide Web (Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web)" [RFC2291].

Dieses Dokument spezifiziert nicht die von [RFC2291] vorgeschlagenen Versionierungsoperationen. Diese Arbeit wurde in einem separaten Dokument durchgeführt, „Versionierungserweiterungen für WebDAV (Versioning Extensions to WebDAV)" [RFC3253].

Die folgenden Abschnitte bieten eine detaillierte Einführung in verschiedene WebDAV-Abstraktionen: Ressourceneigenschaften (Resource Properties, Abschnitt 4), Ressourcensammlungen (Collections of Resources, Abschnitt 5), Sperren (Locks, Abschnitt 6) im Allgemeinen und Schreibsperren (Write Locks, Abschnitt 7) im Besonderen.

Diese Abstraktionen werden durch die WebDAV-spezifischen HTTP-Methoden (Abschnitt 9) und die zusätzlichen HTTP-Header (Abschnitt 10), die mit WebDAV-Methoden verwendet werden, manipuliert. Allgemeine Überlegungen zur Behandlung von HTTP-Anfragen und -Antworten in WebDAV finden sich in Abschnitt 8.

Während die von HTTP/1.1 bereitgestellten Statuscodes ausreichen, um die meisten Fehlerbedingungen zu beschreiben, die bei WebDAV-Methoden auftreten, gibt es einige Fehler, die nicht gut in die bestehenden Kategorien passen. Diese Spezifikation definiert zusätzliche Statuscodes, die für WebDAV-Methoden entwickelt wurden (Abschnitt 11), und beschreibt bestehende HTTP-Statuscodes (Abschnitt 12), wie sie in WebDAV verwendet werden. Da einige WebDAV-Methoden über viele Ressourcen hinweg operieren können, wurde die Multi-Status-Antwort (Multi-Status Response, Abschnitt 13) eingeführt, um Statusinformationen für mehrere Ressourcen zurückzugeben. Schließlich führt diese Version von WebDAV Vorbedingung- und Nachbedingung-XML-Elemente (Precondition/Postcondition, Abschnitt 16) in Fehlerantwortkörpern ein.

WebDAV verwendet XML ([REC-XML]) für Eigenschaftsnamen und einige Werte und verwendet auch XML zum Marshalling komplexer Anfragen und Antworten. Diese Spezifikation enthält DTD- und Textdefinitionen aller Eigenschaften (Abschnitt 15) und aller anderen XML-Elemente (Abschnitt 14), die beim Marshalling verwendet werden. WebDAV enthält einige spezielle Regeln zur Erweiterung des WebDAV-XML-Marshallings auf rückwärtskompatible Weise (Abschnitt 17).

Den Abschluss der Spezifikation bilden Abschnitte darüber, was es für eine Ressource bedeutet, mit dieser Spezifikation konform zu sein (Abschnitt 18), über Internationalisierungsunterstützung (Abschnitt 19) und über Sicherheit (Abschnitt 20).

2. Notational Conventions (Notationskonventionen)​

Da dieses Dokument eine Reihe von Erweiterungen des HTTP/1.1-Protokolls beschreibt, ist die hier verwendete erweiterte BNF (Augmented BNF) zur Beschreibung von Protokollelementen genau dieselbe wie in Abschnitt 2.1 von [RFC2616] beschrieben, einschließlich der Regeln über implizite lineare Leerzeichen (Implied Linear Whitespace). Da diese erweiterte BNF die in Abschnitt 2.2 von [RFC2616] bereitgestellten grundlegenden Produktionsregeln verwendet, gelten diese Regeln auch für dieses Dokument. Beachten Sie, dass dies nicht die Standard-BNF-Syntax ist, die in anderen RFCs verwendet wird.

Die Schlüsselwörter „MUST", „MUST NOT", „REQUIRED", „SHALL", „SHALL NOT", „SHOULD", „SHOULD NOT", „RECOMMENDED", „MAY" und „OPTIONAL" in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.

Deutsche Entsprechung:

  • MUST (muss): absolute Anforderung
  • MUST NOT (darf nicht): absolutes Verbot
  • REQUIRED (erforderlich): absolute Anforderung
  • SHALL (muss): verpflichtende Anforderung
  • SHALL NOT (darf nicht): verpflichtendes Verbot
  • SHOULD (sollte): stark empfohlen, aber nicht verpflichtend
  • SHOULD NOT (sollte nicht): stark abgeraten, aber nicht verboten
  • RECOMMENDED (empfohlen): empfohlene Praxis
  • MAY (kann): erlaubt, aber optional
  • OPTIONAL (optional): vollständig optional

Beachten Sie, dass in natürlicher Sprache eine Eigenschaft wie die Eigenschaft „creationdate" im „DAV:"-XML-Namespace manchmal der Kürze halber als „DAV:creationdate" bezeichnet wird.

3. Terminology (Terminologie)​

Dieser Abschnitt definiert Schlüsselbegriffe, die in der WebDAV-Spezifikation verwendet werden.

URI/URL​

URI (Uniform Resource Identifier, Einheitlicher Ressourcenbezeichner) und URL (Uniform Resource Locator, Einheitlicher Ressourcenzeiger). Diese Begriffe (und der Unterschied zwischen ihnen) sind in [RFC3986] definiert.

URI/URL Mapping (URI/URL-Zuordnung)​

Eine Beziehung zwischen einem absoluten URI und einer Ressource. Da eine Ressource sowohl über das Netzwerk abrufbare Elemente als auch nicht abrufbare Elemente darstellen kann, ist es möglich, dass eine Ressource null, eine oder viele URI-Zuordnungen hat. Die Zuordnung einer Ressource zu einem „http"-Schema-URI ermöglicht es, HTTP-Protokollanfragen unter Verwendung des URI an die Ressource zu senden.

Path Segment (Pfadsegment)​

Informell die zwischen Schrägstrichen („/") in einem URI gefundenen Zeichen. Formal wie in Abschnitt 3.3 von [RFC3986] definiert.

Collection (Sammlung)​

Informell eine Ressource, die auch als Container für Referenzen auf untergeordnete Ressourcen fungiert. Formal eine Ressource, die eine Menge von Zuordnungen zwischen Pfadsegmenten und Ressourcen enthält und die in Abschnitt 5 definierten Anforderungen erfüllt.

Internal Member (of a Collection) (Internes Mitglied einer Sammlung)​

Informell eine untergeordnete Ressource einer Sammlung. Formal eine Ressource, auf die durch eine in der Sammlung enthaltene Pfadsegmentzuordnung verwiesen wird.

Internal Member URL (of a Collection) (Interne Mitglieds-URL einer Sammlung)​

Eine URL eines internen Mitglieds, bestehend aus der URL der Sammlung (einschließlich abschließendem Schrägstrich) plus dem Pfadsegment, das das interne Mitglied identifiziert.

Member (of a Collection) (Mitglied einer Sammlung)​

Informell ein „Nachkomme" einer Sammlung. Formal ein internes Mitglied der Sammlung oder, rekursiv, ein Mitglied eines internen Mitglieds.

Member URL (of a Collection) (Mitglieds-URL einer Sammlung)​

Eine URL, die entweder eine interne Mitglieds-URL der Sammlung selbst ist oder eine interne Mitglieds-URL eines Mitglieds dieser Sammlung ist.

Property (Eigenschaft)​

Ein Name/Wert-Paar, das beschreibende Informationen über eine Ressource enthält.

Live Property (Live-Eigenschaft)​

Eine Eigenschaft, deren Semantik und Syntax vom Server erzwungen werden. Beispielsweise wird der Wert der Live-Eigenschaft DAV:getcontentlength, die Länge der von einer GET-Anfrage zurückgegebenen Entität, automatisch vom Server berechnet.

Dead Property (Dead-Eigenschaft)​

Eine Eigenschaft, deren Semantik und Syntax nicht vom Server erzwungen werden. Der Server zeichnet nur den Wert einer Dead-Eigenschaft auf; der Client ist für die Aufrechterhaltung der Konsistenz der Syntax und Semantik einer Dead-Eigenschaft verantwortlich.

Principal (Prinzipal)​

Ein eigenständiger menschlicher oder rechnerischer Akteur, der den Zugriff auf Netzwerkressourcen initiiert.

State Token (Zustandstoken)​

Ein URI, der einen Zustand einer Ressource darstellt. Sperrtokens (Lock Tokens) sind die einzigen in dieser Spezifikation definierten Zustandstokens.

4. Data Model for Resource Properties (Datenmodell für Ressourceneigenschaften)​

4.1 The Resource Property Model (Das Ressourceneigenschaftsmodell)​

Properties (Eigenschaften) sind Datenstücke, die den Zustand einer Ressource beschreiben. Eigenschaften sind Daten über Daten.

Eigenschaften werden in verteilten Autorenumgebungen verwendet, um eine effiziente Entdeckung und Verwaltung von Ressourcen zu ermöglichen. Beispielsweise könnte eine 'subject'-Eigenschaft die Indexierung aller Ressourcen nach ihrem Thema ermöglichen, und eine 'author'-Eigenschaft könnte die Entdeckung ermöglichen, welche Autoren welche Dokumente geschrieben haben.

Das DAV-Eigenschaftsmodell besteht aus Name/Wert-Paaren. Der Name einer Eigenschaft identifiziert die Syntax und Semantik der Eigenschaft und bietet eine Adresse, über die auf ihre Syntax und Semantik verwiesen werden kann.

Es gibt zwei Kategorien von Eigenschaften: "live" und "dead". Eine live-Eigenschaft hat ihre Syntax und Semantik, die vom Server durchgesetzt werden. Live-Eigenschaften umfassen Fälle, in denen a) der Wert einer Eigenschaft vom Server geschützt und gepflegt wird, und b) der Wert der Eigenschaft vom Client gepflegt wird, der Server jedoch eine Syntaxprüfung der übermittelten Werte durchführt. Alle Instanzen einer bestimmten live-Eigenschaft MÜSSEN der Definition entsprechen, die mit diesem Eigenschaftsnamen verbunden ist. Eine dead-Eigenschaft hat ihre Syntax und Semantik, die vom Client durchgesetzt werden; der Server zeichnet lediglich den Wert der Eigenschaft wörtlich auf.

4.2 Properties and HTTP Headers (Eigenschaften und HTTP-Header)​

Eigenschaften existieren bereits in begrenztem Sinne in HTTP-Nachrichtenheadern. In verteilten Autorenumgebungen ist jedoch eine relativ große Anzahl von Eigenschaften erforderlich, um den Zustand einer Ressource zu beschreiben, und das Setzen/Zurückgeben aller über HTTP-Header ist ineffizient. Daher wird ein Mechanismus benötigt, der es einem Principal ermöglicht, eine Menge von Eigenschaften zu identifizieren, an denen der Principal interessiert ist, und nur diese Eigenschaften zu setzen oder abzurufen.

4.3 Property Values (Eigenschaftswerte)​

Der Wert einer Eigenschaft ist immer ein wohlgeformtes XML-Fragment.

XML wurde gewählt, weil es ein flexibles, selbstbeschreibendes, strukturiertes Datenformat ist, das umfangreiche Schemadefinitionen unterstützt, und wegen seiner Unterstützung für mehrere Zeichensätze. Die selbstbeschreibende Natur von XML ermöglicht es, den Wert jeder Eigenschaft durch Hinzufügen von Elementen zu erweitern. Clients werden nicht brechen, wenn sie auf Erweiterungen stoßen, weil sie immer noch die im ursprünglichen Schema angegebenen Daten haben werden und Elemente ignorieren MÜSSEN, die sie nicht verstehen.

Die Unterstützung von XML für mehrere Zeichensätze ermöglicht es, jede menschenlesbare Eigenschaft in einem dem Benutzer vertrauten Zeichensatz zu codieren und zu lesen. Die Unterstützung von XML für mehrere menschliche Sprachen unter Verwendung des "xml:lang"-Attributs behandelt Fälle, in denen derselbe Zeichensatz von mehreren menschlichen Sprachen verwendet wird. Beachten Sie, dass der xml:lang-Geltungsbereich rekursiv ist, sodass ein xml:lang-Attribut auf jedem Element, das ein Eigenschaftsnamenselement enthält, auf den Eigenschaftswert angewendet wird, es sei denn, es wurde durch ein lokal begrenztes Attribut überschrieben. Beachten Sie, dass eine Eigenschaft nur einen Wert in einer Sprache hat (oder die Sprache KANN undefiniert bleiben); eine Eigenschaft hat nicht mehrere Werte in verschiedenen Sprachen oder einen einzelnen Wert in mehreren Sprachen.

Eine Eigenschaft wird immer durch ein XML-Element dargestellt, das aus dem Eigenschaftsnamen besteht, genannt "property name element". Das einfachste Beispiel ist eine leere Eigenschaft, die sich von einer nicht existierenden Eigenschaft unterscheidet:

<R:title xmlns:R="http://www.example.com/ns/"><R:title>

Der Wert der Eigenschaft erscheint innerhalb des Eigenschaftsnamenselements. Der Wert kann jede Art von wohlgeformtem XML-Inhalt sein, einschließlich reinem Text und gemischtem Inhalt. Server MÜSSEN die folgenden XML Information Items (unter Verwendung der Terminologie aus [REC-XML-INFOSET]) bei der Speicherung und Übertragung von dead-Eigenschaften beibehalten:

Für das Eigenschaftsname-Element Information Item selbst:

  • [namespace name]
  • [local name]
  • [attributes] mit dem Namen "xml:lang" oder jedes solche Attribut im Geltungsbereich
  • [children] vom Typ element oder character

Für alle Element Information Items im Eigenschaftswert:

  • [namespace name]
  • [local name]
  • [attributes]
  • [children] vom Typ element oder character

Für Attribute Information Items im Eigenschaftswert:

  • [namespace name]
  • [local name]
  • [normalized value]

Für Character Information Items im Eigenschaftswert:

  • [character code]

Da Präfixe in einigen XML-Vokabularen (z. B. XPath und XML Schema) verwendet werden, SOLLTEN Server für jedes Information Item im Wert beibehalten:

  • [prefix]

XML Infoset-Attribute, die oben nicht aufgeführt sind, KÖNNEN vom Server beibehalten werden, aber Clients DÜRFEN NICHT darauf vertrauen, dass sie beibehalten werden. Die obigen Regeln würden auch standardmäßig für live-Eigenschaften gelten, sofern nicht anders definiert.

Server MÜSSEN das XML-Attribut xml:space ignorieren, falls vorhanden, und es niemals verwenden, um die Leerzeichenbehandlung zu ändern. Leerzeichen in Eigenschaftswerten sind signifikant.

4.3.1 Beispiel - Eigenschaft mit gemischtem Inhalt​

Betrachten Sie eine vom Client wie folgt erstellte dead-Eigenschaft 'author':

<D:prop xml:lang="en" xmlns:D="DAV:">
  <x:author xmlns:x='http://example.com/ns'>
    <x:name>Jane Doe<x:name>
    <!-- Jane's contact info -->
    &lt;x:uri type='email'
           added='2005-11-26'>mailto:[email protected]&lt;x:uri>
    &lt;x:uri type='web'
           added='2005-11-27'>http://www.example.com&lt;x:uri>
    &lt;x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
      Jane has been working way &lt;h:em>too&lt;h:em> long on the
      long-awaited revision of <![CDATA[&lt;RFC2518>]]>.
    &lt;x:notes>
  &lt;x:author>
&lt;D:prop>

Wenn diese Eigenschaft angefordert wird, könnte ein Server zurückgeben:

&lt;D:prop xmlns:D='DAV:'>&lt;author
        xml:lang='en'
        xmlns:x='http://example.com/ns'
        xmlns='http://example.com/ns'
        xmlns:h='http://www.w3.org/1999/xhtml'>
    &lt;x:name>Jane Doe&lt;x:name>
    &lt;x:uri   added="2005-11-26" type="email"
      >mailto:[email protected]&lt;x:uri>
    &lt;x:uri   added="2005-11-27" type="web"
      >http://www.example.com&lt;x:uri>
    &lt;x:notes>
      Jane has been working way &lt;h:em>too&lt;h:em> long on the
      long-awaited revision of &lt;RFC2518&gt;.
    &lt;x:notes>
  &lt;/author>
&lt;D:prop>

Beachten Sie in diesem Beispiel:

  • Das [prefix] für den Eigenschaftsnamen selbst wurde nicht beibehalten, da es nicht signifikant ist, während alle anderen [prefix]-Werte beibehalten wurden,
  • Attributwerte wurden mit doppelten Anführungszeichen anstelle von einfachen Anführungszeichen neu geschrieben (Anführungsstil ist nicht signifikant), und die Attributreihenfolge wurde nicht beibehalten,
  • das xml:lang-Attribut wurde auf dem Eigenschaftsnamenselement selbst zurückgegeben (es war im Geltungsbereich, als die Eigenschaft gesetzt wurde, aber die genaue Position in der Antwort wird nicht als signifikant betrachtet, solange es im Geltungsbereich ist),
  • Leerzeichen zwischen Tags wurden überall beibehalten (Leerzeichen zwischen Attributen nicht),
  • CDATA-Kapselung wurde durch Zeichen-Escaping ersetzt (das Gegenteil wäre auch legal),
  • das Kommentarelement wurde entfernt (ebenso wie ein Processing-Instruction-Element).

Implementierungshinweis: Es gibt Fälle wie Bearbeitungsszenarien, in denen Clients verlangen können, dass XML-Inhalte Zeichen für Zeichen beibehalten werden (wie Attributreihenfolge oder Anführungsstil). In diesem Fall sollten Clients erwägen, einen reinen Texteigenschaftswert zu verwenden, indem sie alle Zeichen mit besonderer Bedeutung beim XML-Parsing escapen.

4.4 Property Names (Eigenschaftsnamen)​

Ein Eigenschaftsname ist ein universell eindeutiger Bezeichner, der mit einem Schema verbunden ist, das Informationen über die Syntax und Semantik der Eigenschaft bereitstellt.

Da der Name einer Eigenschaft universell eindeutig ist, können Clients sich auf konsistentes Verhalten für eine bestimmte Eigenschaft über mehrere Ressourcen hinweg, auf demselben und über verschiedene Server hinweg verlassen, solange diese Eigenschaft auf den betreffenden Ressourcen "live" ist und die Implementierung der live-Eigenschaft ihrer Definition treu ist.

Der XML-Namespace-Mechanismus, der auf URIs ([RFC3986]) basiert, wird zur Benennung von Eigenschaften verwendet, da er Namespace-Kollisionen verhindert und unterschiedliche Grade der administrativen Kontrolle bietet.

Der Eigenschaften-Namespace ist flach; das heißt, keine Hierarchie von Eigenschaften wird explizit erkannt. Wenn also eine Eigenschaft A und eine Eigenschaft A/B auf einer Ressource existieren, wird keine Beziehung zwischen den beiden Eigenschaften erkannt. Es wird erwartet, dass schließlich eine separate Spezifikation erstellt wird, die Probleme im Zusammenhang mit hierarchischen Eigenschaften behandelt.

Schließlich ist es nicht möglich, dieselbe Eigenschaft zweimal auf einer einzigen Ressource zu definieren, da dies zu einer Kollision im Eigenschaften-Namespace der Ressource führen würde.

4.5 Source Resources and Output Resources (Quellressourcen und Ausgaberessourcen)​

Einige HTTP-Ressourcen werden dynamisch vom Server generiert. Für diese Ressourcen existiert vermutlich irgendwo Quellcode, der regelt, wie diese Ressource generiert wird. Die Beziehung von Quelldateien zu Ausgabe-HTTP-Ressourcen kann eins zu eins, eins zu viele, viele zu eins oder viele zu viele sein. Es gibt keinen Mechanismus in HTTP, um zu bestimmen, ob eine Ressource überhaupt dynamisch ist, geschweige denn, wo ihre Quelldateien existieren oder wie sie zu erstellen sind. Obwohl dieses Problem sinnvoll gelöst werden könnte, wurden interoperable WebDAV-Implementierungen weithin eingesetzt, ohne dieses Problem tatsächlich zu lösen, indem nur mit statischen Ressourcen gearbeitet wurde. Daher wird das Quell- vs. Ausgabeproblem in dieser Spezifikation nicht gelöst und wurde auf ein separates Dokument verschoben.

5. Collections of Web Resources (Sammlungen von Web-Ressourcen)​

Dieser Abschnitt bietet eine Beschreibung eines Typs von Web-Ressource, der Sammlung, und erörtert ihre Interaktionen mit dem HTTP-URL-Namespace und mit HTTP-Methoden. Der Zweck einer Sammlungsressource besteht darin, sammlungsähnliche Objekte (z. B. Dateisystemverzeichnisse) innerhalb des Namespace eines Servers zu modellieren.

Alle DAV-konformen Ressourcen MÜSSEN das hier spezifizierte HTTP-URL-Namespace-Modell unterstützen.

5.1 HTTP URL Namespace Model (HTTP-URL-Namespace-Modell)​

Der HTTP-URL-Namespace ist ein hierarchischer Namespace, bei dem die Hierarchie durch das Zeichen "/" begrenzt wird.

Ein HTTP-URL-Namespace wird als konsistent bezeichnet, wenn er die folgenden Bedingungen erfüllt: Für jede URL in der HTTP-Hierarchie existiert eine Sammlung, die diese URL als interne Mitglieds-URL enthält. Die Wurzel oder Top-Level-Sammlung des betrachteten Namespace ist von der vorherigen Regel ausgenommen. Die Top-Level-Sammlung des betrachteten Namespace ist nicht notwendigerweise die durch den absoluten Pfad '/' identifizierte Sammlung -- sie kann durch ein oder mehrere Pfadsegmente identifiziert werden (z. B. /servlets/webdav/...)

Weder HTTP/1.1 noch WebDAV erfordern, dass der gesamte HTTP-URL-Namespace konsistent ist -- eine WebDAV-kompatible Ressource hat möglicherweise keine übergeordnete Sammlung. Bestimmte WebDAV-Methoden dürfen jedoch keine Ergebnisse produzieren, die Namespace-Inkonsistenzen verursachen.

Wie in [RFC2616] und [RFC3986] impliziert, KANN jede Ressource, einschließlich Sammlungsressourcen, durch mehr als einen URI identifiziert werden. Beispielsweise könnte eine Ressource durch mehrere HTTP-URLs identifiziert werden.

5.2 Collection Resources (Sammlungsressourcen)​

Sammlungsressourcen unterscheiden sich von anderen Ressourcen dadurch, dass sie auch als Container fungieren. Einige HTTP-Methoden gelten nur für eine Sammlung, aber einige gelten für einige oder alle Ressourcen innerhalb des durch die Sammlung definierten Containers. Wenn der Umfang einer Methode nicht klar ist, kann der Client angeben, welche Tiefe anzuwenden ist. Die Tiefe kann entweder null Ebenen (nur die Sammlung), eine Ebene (die Sammlung und direkt enthaltene Ressourcen) oder unendliche Ebenen (die Sammlung und alle rekursiv enthaltenen Ressourcen) sein.

Der Zustand einer Sammlung besteht mindestens aus einer Menge von Zuordnungen zwischen Pfadsegmenten und Ressourcen sowie einer Menge von Eigenschaften der Sammlung selbst. In diesem Dokument wird gesagt, dass eine Ressource B in der Sammlungsressource A enthalten ist, wenn es eine Pfadsegmentzuordnung gibt, die auf B abbildet und die in A enthalten ist. Eine Sammlung MUSS höchstens eine Zuordnung für ein gegebenes Pfadsegment enthalten, d. h., es ist illegal, dasselbe Pfadsegment auf mehr als eine Ressource abzubilden.

Auf Sammlungen definierte Eigenschaften verhalten sich genau wie Eigenschaften auf Nicht-Sammlungsressourcen. Eine Sammlung KANN zusätzlichen Zustand haben, wie z. B. von GET zurückgegebene Entity-Bodies.

Für alle WebDAV-konformen Ressourcen A und B, identifiziert durch die URLs "U" bzw. "V", sodass "V" gleich "U/SEGMENT" ist, MUSS A eine Sammlung sein, die eine Zuordnung von "SEGMENT" zu B enthält. Wenn also Ressource B mit URL http://example.com/bar/blah WebDAV-konform ist und Ressource A mit URL http://example.com/bar/ WebDAV-konform ist, dann muss Ressource A eine Sammlung sein und genau eine Zuordnung von "blah" zu B enthalten.

Obwohl eine Zuordnung üblicherweise aus einem einzelnen Segment und einer Ressource besteht, besteht eine Zuordnung im Allgemeinen aus einer Menge von Segmenten und einer Ressource. Dies ermöglicht es einem Server, eine Menge von Segmenten als äquivalent zu behandeln (d. h. entweder sind alle Segmente derselben Ressource zugeordnet, oder keines der Segmente ist einer Ressource zugeordnet). Beispielsweise behandelt ein Server, der eine Groß-/Kleinschreibungs-Faltung an Segmenten durchführt, die Segmente "ab", "Ab", "aB" und "AB" als äquivalent. Ein Client kann dann jedes dieser Segmente verwenden, um die Ressource zu identifizieren. Beachten Sie, dass ein PROPFIND-Ergebnis eines dieser äquivalenten Segmente auswählt, um die Zuordnung zu identifizieren, sodass es ein PROPFIND-Antwortelement pro Zuordnung gibt, nicht eines pro Segment in der Zuordnung.

Sammlungsressourcen KÖNNEN Zuordnungen zu nicht-WebDAV-konformen Ressourcen in der HTTP-URL-Namespace-Hierarchie haben, sind aber nicht dazu verpflichtet. Wenn beispielsweise Ressource X mit URL http://example.com/bar/blah nicht WebDAV-konform ist und Ressource A mit URL http://example.com/bar/ eine WebDAV-Sammlung identifiziert, dann kann A eine Zuordnung von "blah" zu X haben oder nicht.

Wenn eine WebDAV-konforme Ressource keine WebDAV-konformen internen Mitglieder in der HTTP-URL-Namespace-Hierarchie hat, dann ist die WebDAV-konforme Ressource nicht erforderlich, eine Sammlung zu sein.

Es gibt eine etablierte Konvention, dass, wenn auf eine Sammlung mit ihrem Namen ohne abschließenden Schrägstrich verwiesen wird, der Server die Anfrage so behandeln KANN, als ob der abschließende Schrägstrich vorhanden wäre. In diesem Fall SOLLTE er einen Content-Location-Header in der Antwort zurückgeben, der auf die URL zeigt, die mit "/" endet. Wenn beispielsweise ein Client eine Methode auf http://example.com/blah (ohne abschließenden Schrägstrich) aufruft, kann der Server antworten, als ob die Operation auf http://example.com/blah/ (mit abschließendem Schrägstrich) aufgerufen worden wäre, und sollte einen Content-Location-Header mit dem Wert http://example.com/blah/ zurückgeben. Wo immer ein Server eine URL erzeugt, die auf eine Sammlung verweist, SOLLTE der Server den abschließenden Schrägstrich einschließen. Im Allgemeinen SOLLTEN Clients die Form mit abschließendem Schrägstrich von Sammlungsnamen verwenden. Wenn Clients nicht die Form mit abschließendem Schrägstrich verwenden, muss der Client darauf vorbereitet sein, eine Weiterleitungsantwort zu sehen. Clients werden feststellen, dass die DAV:resourcetype-Eigenschaft zuverlässiger als die URL ist, um herauszufinden, ob eine Ressource eine Sammlung ist.

Clients MÜSSEN in der Lage sein, den Fall zu unterstützen, in dem WebDAV-Ressourcen in Nicht-WebDAV-Ressourcen enthalten sind. Wenn beispielsweise eine OPTIONS-Antwort von http://example.com/servlet/dav/collection WebDAV-Unterstützung anzeigt, kann der Client nicht davon ausgehen, dass http://example.com/servlet/dav/ oder sein Elternteil notwendigerweise WebDAV-Sammlungen sind.

Ein typisches Szenario, in dem zugeordnete URLs nicht als Mitglieder ihrer übergeordneten Sammlung erscheinen, ist der Fall, in dem ein Server Links oder Weiterleitungen zu Nicht-WebDAV-Ressourcen zulässt. Beispielsweise erscheint "/col/link" möglicherweise nicht als Mitglied von "/col/", obwohl der Server mit einem 302-Status auf eine GET-Anfrage an "/col/link" antworten würde; daher wäre die URL "/col/link" tatsächlich zugeordnet. Ebenso könnte eine dynamisch generierte Seite eine URL-Zuordnung von "/col/index.html" haben, sodass diese Ressource mit 200 OK auf eine GET-Anfrage antworten könnte, aber dennoch nicht als Mitglied von "/col/" erscheint.

Einige Zuordnungen zu sogar WebDAV-konformen Ressourcen erscheinen möglicherweise nicht in der übergeordneten Sammlung. Ein Beispiel für diesen Fall sind Server, die mehrere Alias-URLs für jede WebDAV-konforme Ressource unterstützen. Ein Server kann URLs implementieren, die nicht zwischen Groß- und Kleinschreibung unterscheiden, sodass "/col/a" und "/col/A" dieselbe Ressource identifizieren, aber beim Auflisten der Mitglieder von "/col" nur entweder "a" oder "A" gemeldet wird. In Fällen, in denen ein Server eine Menge von Segmenten als äquivalent behandelt, MUSS der Server in PROPFIND-Antworten nur ein bevorzugtes Segment pro Zuordnung, konsistent gewählt, offenlegen.

6. Locking (Sperren)​

Die Fähigkeit, eine Ressource zu sperren, bietet einen Mechanismus zur Serialisierung des Zugriffs auf diese Ressource. Mit einer Sperre kann ein Authoring-Client eine vernünftige Garantie bieten, dass ein anderer Prinzipal die Ressource nicht ändert, während sie bearbeitet wird. Auf diese Weise kann ein Client das Problem des „verlorenen Updates (Lost Update)" verhindern.

Diese Spezifikation erlaubt es, dass Sperren über zwei vom Client angegebene Parameter variieren: die Anzahl der beteiligten Prinzipale (exklusive vs. gemeinsame Sperren) und die Art des zu gewährenden Zugriffs. Dieses Dokument definiert das Sperren nur für einen Zugriffstyp: Schreiben (Write). Die Syntax ist jedoch erweiterbar und ermöglicht die eventuelle Spezifikation des Sperrens für andere Zugriffstypen.

6.1 Lock Model (Sperrmodell)​

Dieser Abschnitt bietet eine nicht normative Beschreibung des WebDAV-Sperrens.

Eine Sperre wird durch ein Sperrtoken (Lock Token) identifiziert. Sperrtokens sind URLs und können über HTTP übertragen werden. Ein Sperrtoken ist nur mit einer Sperre verbunden.

Sperren können exklusiv oder gemeinsam sein. Der Sperrtyp bestimmt, wie der Server Anfragen an die gesperrte Ressource behandelt:

Exklusive Sperre (Exclusive Lock):

  • Nur der Prinzipal, der die Sperre erstellt hat, kann die Ressource ändern
  • Verhindert, dass andere Prinzipale eine konfligierende Sperre erhalten

Gemeinsame Sperre (Shared Lock):

  • Mehrere Prinzipale können gemeinsame Sperren halten
  • Alle Prinzipale, die gemeinsame Sperren halten, können die Ressource ändern
  • Verhindert, dass Prinzipale ohne Sperren die Ressource ändern

Sperren können unterschiedliche Bereiche haben:

  • Direkte Sperre (Direct Lock): Die Sperre gilt direkt für die Ressource
  • Tiefensperre (Depth Lock): Die Sperre gilt für die Ressource und alle ihre Mitglieder

Für Sammlungen kann die Tiefe angegeben werden:

  • Depth: 0: Sperrt nur die Sammlung selbst
  • Depth: infinity: Sperrt die Sammlung und alle ihre Mitglieder (rekursiv)

6.2 Exclusive vs. Shared Locks (Exklusive vs. gemeinsame Sperren)​

Der häufigste Sperrtyp ist die exklusive Sperre (Exclusive Lock). Der Zweck einer exklusiven Sperre besteht darin, die Bearbeitungsrichtlinie eines bestimmten Prinzipals durchzusetzen. Eine häufige Verwendung einer exklusiven Sperre besteht darin, zu verhindern, dass verschiedene Prinzipale eine Ressource während einer langen Authoring-Sitzung ändern.

Gemeinsame Sperren (Shared Locks) sind für kollaboratives Authoring konzipiert, bei dem eine Gruppe von Prinzipalen eine Ressource gleichzeitig ändern muss. Das Hauptmerkmal gemeinsamer Sperren ist, dass mehrere Prinzipale gemeinsame Sperren halten können, aber exklusive Sperren alle anderen Sperren ausschließen.

Sperrkompatibilitätstabelle:

Aktueller ZustandGemeinsame SperranfrageExklusive Sperranfrage
Keine✅ Wahr✅ Wahr
Gemeinsame Sperre✅ Wahr❌ Falsch
Exklusive Sperre❌ Falsch❌ Falsch

6.3 Required Support (Erforderliche Unterstützung)​

Ein Server muss (MUST) exklusive Schreibsperren (Exclusive Write Locks) unterstützen.

Ein Server kann (MAY) gemeinsame Schreibsperren (Shared Write Locks) unterstützen. Wenn ein Server keine gemeinsamen Schreibsperren unterstützt, muss (MUST) der Server einen Fehler zurückgeben, wenn ein Client eine gemeinsame Schreibsperre anfordert.

6.4 Lock Creator and Privileges (Sperrersteller und Berechtigungen)​

Eine Sperre ist mit dem Prinzipal verbunden, der die Sperre erstellt hat. Nur Prinzipale mit dem entsprechenden Sperrtoken können eine Ressource entsperren. Dies stellt sicher, dass der Sperrersteller die Kontrolle über den Lebenszyklus der Sperre hat.

Der Prinzipal, der eine Sperre erstellt, muss über die Berechtigungen verfügen, Sperren auf der Ressource zu erstellen. Die spezifischen Berechtigungsanforderungen werden durch die Zugriffssteuerungsrichtlinie des Servers bestimmt.

6.5 Lock Tokens (Sperrtokens)​

Ein Sperrtoken (Lock Token) ist eine URL, die eine Sperre eindeutig identifiziert. Sperrtokens verwenden typischerweise das URI-Schema opaquelocktoken: (siehe Anhang C).

Sperrtoken-Eigenschaften:

  • Globale Eindeutigkeit: Jedes Sperrtoken ist global eindeutig
  • Unvorhersehbarkeit: Sperrtokens sollten unvorhersehbar sein, um unbefugten Zugriff zu verhindern
  • URL-Format: Sperrtokens sind gültige URLs

Beispiel-Sperrtoken:

opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Clients übermitteln Sperrtokens durch:

  • Einbeziehung des Sperrtokens in den If-Header
  • Einbeziehung des Sperrtokens in den Lock-Token-Header (nur für UNLOCK-Methode)

6.6 Lock Timeout (Sperr-Timeout)​

Sperren haben eine begrenzte Lebensdauer. Der Server weist jeder Sperre einen Timeout-Wert zu, nach dem die Sperre automatisch abläuft.

Timeout-Eigenschaften:

  • Clients können einen Timeout-Wert im Timeout-Request-Header vorschlagen
  • Server können den Vorschlag des Clients ignorieren und ihren eigenen Timeout-Wert zuweisen
  • Server müssen (MUST) den tatsächlichen Timeout-Wert in der Sperrantwort zurückgeben
  • Clients können die Lebensdauer der Sperre durch Aktualisierung der Sperre verlängern

Timeout-Format:

Timeout: Second-4100
Timeout: Infinite

Best Practices:

  • Server sollten (SHOULD) Clients erlauben, Sperren zu aktualisieren
  • Clients sollten (SHOULD) langfristige Sperren regelmäßig aktualisieren
  • Clients sollten (SHOULD) Ressourcen entsperren, wenn die Bearbeitung abgeschlossen ist

6.7 Lock Capability Discovery (Erkennung der Sperrfähigkeiten)​

Vor dem Versuch, eine Ressource zu sperren, können Clients die Sperrfähigkeiten des Servers mithilfe der OPTIONS-Methode entdecken. Der DAV-Header in der Antwort zeigt die WebDAV-Konformitätsklasse des Servers an, die Sperrunterstützung einschließt.

6.8 Active Lock Discovery (Erkennung aktiver Sperren)​

Clients können aktive Sperren auf einer Ressource mithilfe der PROPFIND-Methode entdecken, um die DAV:lockdiscovery-Eigenschaft abzurufen. Diese Eigenschaft enthält Informationen über alle aktiven Sperren auf der Ressource, einschließlich Sperrtyp, Bereich, Tiefe, Eigentümer, Timeout und Sperrtoken.

7. Write Lock (Schreibsperre)​

Dieser Abschnitt beschreibt die Schreibsperre (Write Lock), den einzigen in dieser Spezifikation definierten Sperrtyp. Eine Schreibsperre ist eine Sperre, die dem Sperrinhaber das Recht gewährt, die Ressource zu ändern. Der Sperrinhaber ist der Prinzipal, der die Sperre erstellt hat.

7.1 Write Locks and Properties (Schreibsperren und Eigenschaften)​

Obwohl diejenigen ohne Schreibsperre den Inhalt einer Ressource nicht ändern dürfen, können (MAY) sie die Dead-Eigenschaften der Ressource ändern. Dies ermöglicht es beispielsweise einem Prinzipal, Kommentare zu einer gesperrten Ressource hinzuzufügen, ohne Schreibzugriff zu benötigen.

Live-Eigenschaften haben typischerweise eine vom Server erzwungene Semantik. Der Server hat daher das Ermessen darüber, ob und wie Änderungen an Live-Eigenschaften erlaubt werden, wenn eine Ressource gesperrt ist. Beispielsweise kann (MAY) ein Server die Änderung von Live-Eigenschaften auch dann erlauben, wenn eine Ressource gesperrt ist.

7.2 Avoiding Lost Updates (Vermeidung verlorener Updates)​

Der Zweck von Schreibsperren besteht darin, verlorene Updates zu verhindern. Ein verlorenes Update tritt auf, wenn mehrere Prinzipale versuchen, eine Ressource ohne Koordination zu ändern, was dazu führt, dass die Änderungen eines oder mehrerer Prinzipale durch nachfolgende Updates überschrieben werden.

Schreibsperren bieten einen Serialisierungsmechanismus: Nur der Sperrinhaber kann die gesperrte Ressource ändern. Dies verhindert das Problem verlorener Updates, indem sichergestellt wird, dass Änderungen sequenziell und nicht gleichzeitig erfolgen.

Beispiel für verlorenes Update-Szenario (ohne Sperre):

  1. Benutzer A ruft Ressourcenversion 1 ab
  2. Benutzer B ruft Ressourcenversion 1 ab
  3. Benutzer A ändert und speichert → erstellt Version 2
  4. Benutzer B ändert (basierend auf Version 1) und speichert → erstellt Version 3, überschreibt die Änderungen von A

Mit Schreibsperre:

  1. Benutzer A sperrt die Ressource
  2. Benutzer B versucht zu ändern → erhält 423 Locked-Fehler
  3. Benutzer A ändert und entsperrt
  4. Benutzer B kann jetzt sperren und ändern

7.3 Write Locks and Unmapped URLs (Schreibsperren und nicht zugeordnete URLs)​

Eine erfolgreiche LOCK-Anfrage auf einer nicht zugeordneten URL erstellt eine leere Ressource, die gesperrt ist. Dieser Mechanismus ermöglicht es Clients, eine URL zu reservieren, bevor der Ressourceninhalt erstellt wird.

Wenn eine gesperrte leere Ressource erstellt wird:

  • Die Ressource hat keinen Inhalt (Entität mit Nulllänge)
  • Die Ressource ist mit der angegebenen Sperre gesperrt
  • Ein nachfolgendes PUT oder MKCOL kann der Ressource Inhalt hinzufügen
  • Das Sperrtoken muss mit der PUT- oder MKCOL-Anfrage übermittelt werden

Dieser „Lock-null-Ressourcen"-Mechanismus wird in Anhang D detailliert beschrieben.

7.4 Write Locks and Collections (Schreibsperren und Sammlungen)​

Eine Schreibsperre auf einer Sammlung sperrt die Sammlungsressource selbst und verhindert Änderungen an der Mitgliedschaft der Sammlung (Hinzufügen oder Entfernen interner Mitglieder).

Wenn eine Sperre mit unendlicher Tiefe auf eine Sammlung angewendet wird:

  • Die Sammlung selbst wird gesperrt
  • Alle internen Mitglieder werden gesperrt
  • Alle Nachfolgerressourcen werden rekursiv gesperrt
  • Neue Mitglieder, die der Sammlung hinzugefügt werden, werden automatisch gesperrt

Sperrvererbung: Wenn eine neue Ressource zu einer gesperrten Sammlung (mit unendlicher Tiefe) hinzugefügt wird, erbt die neue Ressource die Sperre von der übergeordneten Sammlung.

7.5 Write Locks and the If Request Header (Schreibsperren und der If-Request-Header)​

Clients übermitteln Sperrtokens mit dem If-Request-Header. Dieser Header ermöglicht die bedingte Ausführung von Methoden basierend auf dem Vorhandensein von Sperrtokens.

Die If-Header-Syntax unterstützt:

  • Einzelne Sperrtokens
  • Mehrere Sperrtokens (für mehrere Sperren)
  • Markierte Listen (Zuordnung von Tokens zu bestimmten URLs)
  • NOT-Bedingungen (Anforderung der Abwesenheit von Sperren)

7.5.1 Example - Write Lock and COPY (Beispiel - Schreibsperre und COPY)​

COPY /source HTTP/1.1
Host: example.com
Destination: http://example.com/destination
If: `http://example.com/destination` (&lt;opaquelocktoken:token123>)

Diese Anfrage kopiert /source nach /destination, aber nur, wenn der Client das Sperrtoken für /destination hält.

7.5.2 Example - Deleting a Member of a Locked Collection (Beispiel - Löschen eines Mitglieds einer gesperrten Sammlung)​

DELETE /folder/file.txt HTTP/1.1
Host: example.com
If: `http://example.com/folder/` (&lt;opaquelocktoken:folder-token>)

Um ein Mitglied einer gesperrten Sammlung zu löschen, muss der Client das Sperrtoken für die Sammlung übermitteln.

7.6 Write Locks and COPY/MOVE (Schreibsperren und COPY/MOVE)​

Die COPY-Methode erstellt eine neue Ressource am Ziel. Die neue Ressource wird NICHT automatisch gesperrt, selbst wenn die Quelle gesperrt war. Sperren werden nicht kopiert.

Die MOVE-Methode ist semantisch äquivalent zu COPY gefolgt von DELETE. Die Sperre der Quelle wird entfernt, wenn die Ressource verschoben wird. Das Ziel wird nicht automatisch gesperrt.

Wenn das Ziel eines COPY oder MOVE gesperrt ist, muss der Client das entsprechende Sperrtoken übermitteln, um das Ziel zu überschreiben.

7.7 Refreshing Write Locks (Aktualisierung von Schreibsperren)​

Sperren haben endliche Lebensdauern. Um ein vorzeitiges Ablaufen der Sperre zu verhindern, können Clients Sperren durch Übermittlung einer LOCK-Anfrage mit folgenden Eigenschaften aktualisieren:

  • Dasselbe Sperrtoken im If-Header
  • Kein Request-Body (oder ein leeres lockinfo-Element)

Der Server antwortet mit dem neuen Timeout-Wert. Die Sperrakt ualisierung ermöglicht langfristige Bearbeitungssitzungen ohne Sperrablauf.

Beispiel für Sperraktualisierung:

LOCK /resource HTTP/1.1
Host: example.com
If: (&lt;opaquelocktoken:token123>)
Timeout: Second-3600

Der Server verlängert den Sperr-Timeout und gibt die neue Ablaufzeit zurück.

8. General Request and Response Handling (Allgemeine Anfragen- und Antwortbehandlung)​

8.1 Precedence in Error Handling (Vorrang bei der Fehlerbehandlung)​

Server MÜSSEN Autorisierungsfehler vor anderen Fehlern zurückgeben. Dies vermeidet das Durchsickern von Informationen über geschützte Ressourcen (z. B. ein Client, der feststellt, dass eine versteckte Ressource existiert, indem er eine 423 Locked-Antwort auf eine anonyme Anfrage an die Ressource sieht).

8.2 Use of XML (Verwendung von XML)​

In HTTP/1.1 wurden Methodenparameterinformationen ausschließlich in HTTP-Headern codiert. Im Gegensatz zu HTTP/1.1 codiert WebDAV Methodenparameterinformationen entweder in einem XML-Anfrage-Entity-Body ([REC-XML]) oder in einem HTTP-Header. Die Verwendung von XML zur Codierung von Methodenparametern wurde durch die Fähigkeit motiviert, zusätzliche XML-Elemente zu bestehenden Strukturen hinzuzufügen, um Erweiterbarkeit bereitzustellen; und durch die Fähigkeit von XML, Informationen in ISO 10646-Zeichensätzen zu codieren, um Internationalisierungsunterstützung bereitzustellen.

Zusätzlich zur Codierung von Methodenparametern wird XML in WebDAV verwendet, um die Antworten von Methoden zu codieren, wodurch die Erweiterungs- und Internationalisierungsvorteile von XML für Methodenausgabe sowie -eingabe bereitgestellt werden.

Wenn XML für einen Anfrage- oder Antwortkörper verwendet wird, SOLLTE der Content-Type-Typ application/xml sein. Implementierungen MÜSSEN sowohl text/xml als auch application/xml in Anfrage- und Antwortkörpern akzeptieren. Die Verwendung von text/xml ist veraltet.

Alle DAV-konformen Clients und Ressourcen MÜSSEN XML-Parser verwenden, die mit [REC-XML] und [REC-XML-NAMES] konform sind. Alle in Anfragen oder Antworten verwendeten XML MÜSSEN mindestens wohlgeformt sein und Namensräume korrekt verwenden. Wenn ein Server XML erhält, das nicht wohlgeformt ist, MUSS der Server die gesamte Anfrage mit 400 (Bad Request) ablehnen. Wenn ein Client XML erhält, das in einer Antwort nicht wohlgeformt ist, DARF der Client nichts über das Ergebnis der ausgeführten Methode annehmen und SOLLTE den Server als fehlerhaft behandeln.

Beachten Sie, dass die Verarbeitung von XML, das von einer nicht vertrauenswürdigen Quelle übermittelt wurde, Risiken im Zusammenhang mit Datenschutz, Sicherheit und Servicequalität verursachen kann (siehe Abschnitt 20). Server KÖNNEN fragwürdige Anfragen ablehnen (auch wenn sie aus wohlgeformtem XML bestehen), beispielsweise mit einem 400 (Bad Request)-Statuscode und einem optionalen Antwortkörper, der das Problem erklärt.

8.3 URL Handling (URL-Behandlung)​

URLs erscheinen an vielen Stellen in Anfragen und Antworten. Interoperabilitätserfahrungen mit [RFC2518] zeigten, dass viele Clients, die Multi-Status-Antworten parsen, die vollständige Referenzauflösung, die in Abschnitt 5 von [RFC3986] definiert ist, nicht vollständig implementiert haben. Daher müssen Server insbesondere bei der Behandlung von URLs in Antworten vorsichtig sein, um sicherzustellen, dass Clients genügend Kontext haben, um alle URLs interpretieren zu können. Die Regeln in diesem Abschnitt gelten nicht nur für Ressourcen-URLs im 'href'-Element in Multi-Status-Antworten, sondern auch für die Destination- und If-Header-Ressourcen-URLs.

Der Sender hat die Wahl zwischen zwei Ansätzen: Verwendung einer relativen Referenz, die gegen den Request-URI aufgelöst wird, oder eines vollständigen URI. Ein Server MUSS sicherstellen, dass jeder 'href'-Wert innerhalb einer Multi-Status-Antwort dasselbe Format verwendet.

WebDAV verwendet in seinen Erweiterungen nur eine Form relativer Referenz, den absoluten Pfad.

Simple-ref = absolute-URI | ( path-absolute [ "?" query ] )

Die Produktionen absolute-URI, path-absolute und query sind in den Abschnitten 4.3, 3.3 und 3.4 von [RFC3986] definiert.

Innerhalb von Simple-ref-Produktionen DÜRFEN Sender NICHT:

  • Punkt-Segmente ("." oder "..") verwenden, oder
  • Präfixe haben, die nicht mit dem Request-URI übereinstimmen (unter Verwendung der in Abschnitt 3.2.3 von [RFC2616] definierten Vergleichsregeln).

Bezeichner für Sammlungen SOLLTEN mit einem '/'-Zeichen enden.

8.3.1 Beispiel - Korrekte URL-Behandlung​

Betrachten Sie die Sammlung http://example.com/sample/ mit der internen Mitglieds-URL http://example.com/sample/a%20test und der PROPFIND-Anfrage unten:

Anfrage:

PROPFIND /sample/ HTTP/1.1
Host: example.com
Depth: 1

In diesem Fall sollte der Server zwei 'href'-Elemente zurückgeben, die entweder enthalten

  • http://example.com/sample/ und http://example.com/sample/a%20test, oder
  • /sample/ und /sample/a%20test

Beachten Sie, dass, obwohl der Server die Mitgliedsressource intern als 'a test' speichern kann, sie prozentcodiert sein muss, wenn sie innerhalb einer URI-Referenz verwendet wird (siehe Abschnitt 2.1 von [RFC3986]). Beachten Sie auch, dass ein legaler URI immer noch Zeichen enthalten kann, die innerhalb von XML-Zeichendaten maskiert werden müssen, wie das Ampersand-Zeichen.

8.4 Required Bodies in Requests (Erforderliche Körper in Anfragen)​

Einige dieser neuen Methoden definieren keine Körper. Server MÜSSEN alle Anfragen auf einen Körper prüfen, auch wenn ein Körper nicht erwartet wurde. In Fällen, in denen ein Anfragekörper vorhanden ist, aber von einem Server ignoriert würde, MUSS der Server die Anfrage mit 415 (Unsupported Media Type) ablehnen. Dies informiert den Client (der möglicherweise versucht hat, eine Erweiterung zu verwenden), dass der Körper nicht wie vom Client beabsichtigt verarbeitet werden konnte.

8.5 HTTP Headers for Use in WebDAV (HTTP-Header zur Verwendung in WebDAV)​

HTTP definiert viele Header, die in WebDAV-Anfragen und -Antworten verwendet werden können. Nicht alle sind in allen Situationen angemessen, und einige Interaktionen können undefiniert sein. Beachten Sie, dass HTTP 1.1 den Date-Header in allen Antworten erfordert, wenn möglich (siehe Abschnitt 14.18, [RFC2616]).

Der Server MUSS Autorisierungsprüfungen durchführen, bevor er einen bedingten HTTP-Header prüft.

8.6 ETag​

HTTP 1.1 empfiehlt die Verwendung von ETags anstelle von Änderungsdaten zur Cache-Steuerung, und es gibt noch stärkere Gründe, ETags für die Erstellung vorzuziehen. Die korrekte Verwendung von ETags ist in einer verteilten Erstellungsumgebung noch wichtiger, da ETags zusammen mit Sperren erforderlich sind, um das Problem verlorener Updates zu vermeiden. Ein Client könnte beispielsweise eine Sperre nicht erneuern, wenn die Sperre abläuft und der Client versehentlich offline ist oder sich mitten in einem langen Upload befindet. Wenn ein Client die Sperre nicht erneuern kann, ist es durchaus möglich, dass die Ressource immer noch neu gesperrt werden kann und der Benutzer mit der Bearbeitung fortfahren kann, solange in der Zwischenzeit keine Änderungen vorgenommen wurden. ETags sind erforderlich, damit der Client diesen Fall unterscheiden kann. Andernfalls ist der Client gezwungen, den Benutzer zu fragen, ob er die Ressource auf dem Server überschreiben soll, ohne dem Benutzer sogar sagen zu können, ob sie sich geändert hat. Zeitstempel lösen dieses Problem nicht annähernd so gut wie ETags.

Starke ETags sind für Erstellungsanwendungsfälle viel nützlicher als schwache ETags (siehe Abschnitt 13.3.3 von [RFC2616]). Semantische Äquivalenz kann ein nützliches Konzept sein, aber das hängt vom Dokumenttyp und Anwendungstyp ab, und Interoperabilität könnte eine Vereinbarung oder einen Standard außerhalb des Umfangs dieser Spezifikation und HTTP erfordern. Beachten Sie auch, dass schwache ETags bestimmte Einschränkungen in HTTP haben, z. B. können diese nicht in If-Match-Headern verwendet werden.

Beachten Sie, dass die Bedeutung eines ETag in einer PUT-Antwort weder in diesem Dokument noch in RFC 2616 klar definiert ist (d. h., ob der ETag bedeutet, dass die Ressource Byte-für-Byte äquivalent zum Körper der PUT-Anfrage ist, oder ob der Server bei der Speicherung geringfügige Änderungen an der Formatierung oder dem Inhalt des Dokuments vorgenommen haben könnte). Dies ist ein HTTP-Problem, nicht rein ein WebDAV-Problem.

Da Clients möglicherweise gezwungen sind, Benutzer aufzufordern oder geänderte Inhalte zu verwerfen, wenn sich der ETag ändert, SOLLTE ein WebDAV-Server den ETag (oder die Last-Modified-Zeit) für eine Ressource mit unverändertem Körper und Standort NICHT ändern. Der ETag repräsentiert den Zustand des Körpers oder Inhalts der Ressource. Es gibt keine ähnliche Möglichkeit festzustellen, ob sich Eigenschaften geändert haben.

8.7 Including Error Response Bodies (Einbeziehung von Fehlerantwortkörpern)​

HTTP und WebDAV verwendeten die Körper der meisten Fehlerantworten nicht für maschinell analysierbare Informationen, bis die Spezifikation für Versionierungserweiterungen für WebDAV einen Mechanismus einführte, um spezifischere Informationen in den Körper einer Fehlerantwort aufzunehmen (Abschnitt 1.6 von [RFC3253]). Der Fehlerkörpermechanismus ist angemessen für die Verwendung mit jeder Fehlerantwort, die einen Körper aufnehmen kann, aber noch keinen definierten Körper hat. Der Mechanismus ist besonders geeignet, wenn ein Statuscode viele Dinge bedeuten kann (zum Beispiel kann 400 Bad Request bedeuten, dass erforderliche Header fehlen, Header falsch formatiert sind und vieles mehr). Dieser Fehlerkörpermechanismus wird in Abschnitt 16 behandelt.

8.8 Impact of Namespace Operations on Cache Validators (Auswirkung von Namespace-Operationen auf Cache-Validatoren)​

Beachten Sie, dass die HTTP-Antwortheader "Etag" und "Last-Modified" (siehe [RFC2616], Abschnitte 14.19 und 14.29) pro URL (nicht pro Ressource) definiert sind und von Clients zum Caching verwendet werden. Daher müssen Server sicherstellen, dass die Ausführung jeder Operation, die den URL-Namespace betrifft (wie COPY, MOVE, DELETE, PUT oder MKCOL), ihre Semantik beibehält, insbesondere:

  • Für jede gegebene URL MUSS der "Last-Modified"-Wert jedes Mal inkrementiert werden, wenn sich die bei GET zurückgegebene Darstellung ändert (innerhalb der Grenzen der Zeitstempelauflösung).
  • Für jede gegebene URL DARF ein "ETag"-Wert NICHT für verschiedene von GET zurückgegebene Darstellungen wiederverwendet werden.

In der Praxis bedeutet dies, dass Server

  • möglicherweise "Last-Modified"-Zeitstempel für jede Ressource innerhalb des Ziel-Namespace einer Namespace-Operation inkrementieren müssen, es sei denn, sie können dies selektiver tun, und
  • ähnlich möglicherweise "ETag"-Werte für diese Ressourcen neu zuweisen müssen (es sei denn, der Server weist Entity-Tags so zu, dass sie im gesamten vom Server verwalteten URL-Namespace eindeutig sind).

Beachten Sie, dass diese Überlegungen auch für spezifische Anwendungsfälle gelten, wie z. B. die Verwendung von PUT zum Erstellen einer neuen Ressource an einer URL, die zuvor zugeordnet war, aber seitdem gelöscht wurde.

9. HTTP Methods for Distributed Authoring (HTTP-Methoden für verteiltes Authoring)​

Dieses Kapitel beschreibt die von WebDAV definierten HTTP-Methoden und Erweiterungen bestehender HTTP-Methoden.

Übersicht der WebDAV-Methoden​

MethodeZweckZiel
PROPFINDEigenschaften abrufenRessource oder Sammlung
PROPPATCHEigenschaften ändernRessource
MKCOLSammlung erstellenNicht zugeordnete URL
COPYRessource kopierenQuelle und Ziel
MOVERessource verschieben/umbenennenQuelle und Ziel
LOCKRessource sperrenRessource oder Sammlung
UNLOCKRessource entsperrenGesperrte Ressource

9.1 PROPFIND-Methode​

PROPFIND ruft die Eigenschaften ab, die auf der durch den Request-URI identifizierten Ressource definiert sind.

Anforderungstypen: propname, allprop, prop, allprop + include

9.2 PROPPATCH-Methode​

PROPPATCH ändert Eigenschaften einer Ressource.

Operationen: set (erstellen/aktualisieren), remove (löschen)

Atomarität: Alle Operationen müssen (MUST) zusammen erfolgreich sein oder fehlschlagen.

9.3 MKCOL-Methode​

MKCOL erstellt eine neue Sammlungsressource am Request-URI.

9.4 GET, HEAD für Sammlungen​

GET und HEAD können (MAY) bei Sammlungen eine HTML-Verzeichnisliste zurückgeben.

9.5 POST für Sammlungen​

POST fügt Mitglieder zu einer Sammlung hinzu. Der Server bestimmt die URL des neuen Mitglieds.

9.6 DELETE-Methode​

DELETE entfernt die durch den Request-URI identifizierte Ressource.

Für Sammlungen: Löscht die Sammlung und alle Mitglieder rekursiv.

9.7 PUT-Methode​

PUT erstellt oder aktualisiert eine Ressource.

9.8 COPY-Methode​

COPY erstellt ein Duplikat der Quellressource am Ziel.

Header: Destination (erforderlich), Depth, Overwrite

Verhalten: Sperren werden NICHT kopiert.

9.9 MOVE-Methode​

MOVE ist logisch äquivalent zu COPY + DELETE.

Atomarität: MOVE-Operationen müssen (MUST) atomar sein.

9.10 LOCK-Methode​

LOCK erhält eine Sperre auf einer Ressource.

Sperrtypen: Exklusive Schreibsperre, Gemeinsame Schreibsperre

9.11 UNLOCK-Methode​

UNLOCK entfernt die durch das Sperrtoken identifizierte Sperre.

Für vollständige Methodenspezifikationen siehe RFC 4918 Abschnitte 9.1-9.11.

10. HTTP Headers for Distributed Authoring (HTTP-Header für verteiltes Authoring)​

WebDAV definiert mehrere neue HTTP-Header, die zur Unterstützung von Funktionen für verteiltes Authoring (Distributed Authoring) dienen.

10.1 DAV Header​

Der DAV-Header gibt an, welche WebDAV-Konformitätsstufen (Compliance Classes) und optionalen Erweiterungen der Server unterstützt.

Syntax​

DAV: 1, 2, 3, access-control, calendar-access

Konformitätsstufen (Compliance Levels)​

  • 1: Grundlegende WebDAV-Unterstützung (PROPFIND, PROPPATCH, MKCOL, erweiterte GET/HEAD, erweiterte PUT, erweiterte DELETE, OPTIONS, COPY, MOVE)
  • 2: Umfasst Stufe 1 sowie Unterstützung für LOCK und UNLOCK
  • 3: Umfasst Stufe 2 sowie Unterstützung für geordnete Sammlungen (optional)

Verwendung​

OPTIONS-Antwort:

OPTIONS /resource HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
DAV: 1, 2
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK

Der DAV-Header MUSS in allen OPTIONS-Antworten enthalten sein, wenn der Server WebDAV unterstützt. Er DARF NICHT in Anfragen vom Client verwendet werden.

10.2 Depth Header​

Der Depth-Header gibt an, auf welche Tiefe einer Ressourcenhierarchie (Resource Hierarchy) eine Operation angewendet werden soll.

Syntax​

Depth: 0 | 1 | infinity

Bedeutung der Werte​

  • 0: Nur auf die Zielressource selbst anwenden
  • 1: Auf die Ressource und ihre direkten Mitglieder anwenden
  • infinity: Rekursiv auf die Ressource und alle ihre Nachkommen anwenden

Unterstützte Methoden​

MethodeDepth-UnterstützungStandardwert
PROPFIND0, 1, infinityinfinity
COPY0, infinityinfinity
MOVEinfinity (andere Werte werden ignoriert)infinity
LOCK0, infinityinfinity
DELETEwird ignoriert (immer rekursiv)N/A

Beispiele​

PROPFIND /collection/ HTTP/1.1
Host: example.com
Depth: 0

PROPFIND /collection/ HTTP/1.1
Host: example.com
Depth: 1

Server SOLLTEN Anfragen mit Depth: infinity auf Sammlungen (Collections) ablehnen, wenn dies zu einer übermäßigen Serverlast führen würde.

10.3 Destination Header​

Der Destination-Header gibt die Ziel-URL (Destination URI) für COPY- oder MOVE-Operationen an.

Syntax​

Destination: absoluteURI

Anforderungen​

  • Pflichtfeld: COPY- und MOVE-Methoden MÜSSEN diesen Header enthalten
  • Absoluter URI: Der Wert MUSS ein vollständiger absoluter URI sein
  • Gleicher Server: In der Regel wird vorausgesetzt, dass Quelle und Ziel auf demselben Server liegen

Beispiele​

COPY /source/file.txt HTTP/1.1
Host: example.com
Destination: http://example.com/destination/file.txt
Overwrite: T

MOVE /old-name.doc HTTP/1.1
Host: example.com
Destination: http://example.com/new-name.doc

Wenn der Destination-Header bei COPY oder MOVE fehlt, MUSS der Server mit 400 Bad Request antworten.

10.4 If Header​

Der If-Header bietet einen Mechanismus zur bedingten Ausführung (Conditional Execution) von WebDAV-Methoden. Er dient sowohl zur Übermittlung von Sperr-Tokens (Lock Tokens) als auch zur Angabe von ETag-Bedingungen.

Syntax​

Der If-Header kennt zwei Formen:

No-tag-list-Form (gilt für die Anfrage-URI):

If: (<locktoken>) (["etag"])

Tagged-list-Form (gilt für eine bestimmte Ressource):

If: <resource-url> (<locktoken>)

Verwendungszwecke​

  1. Übermittlung von Sperr-Tokens – Nachweis, dass der Client eine Sperre hält
  2. Bedingte Anfragen – Bedingte Ausführung auf Basis von ETags
  3. Logische Verknüpfungen – Unterstützung von AND- und OR-Logik

Beispiele​

Übermittlung eines Sperr-Tokens:

PUT /locked-resource HTTP/1.1
Host: example.com
If: (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
Content-Type: text/plain

Updated content

Mehrere Bedingungen:

DELETE /resource HTTP/1.1
Host: example.com
If: <http://example.com/resource>
    (<urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)
    (["e0-b2-1a2"])

NOT-Bedingung:

If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2>)

Auswertungsregeln des If-Headers​

  1. Sperr-Token-Abgleich – Prüft, ob das übermittelte Token mit der Ressourcensperre übereinstimmt
  2. ETag-Abgleich – Prüft, ob das Entity-Tag übereinstimmt
  3. Logische Auswertung – Auswertung von links nach rechts mit Kurzschlussauswertung (Short-Circuit Evaluation)

Anwendungsszenarien​

Szenario 1: Gesperrte Ressource ändern

PUT /locked-doc HTTP/1.1
If: (<urn:uuid:lock-token-here>)

Szenario 2: COPY auf gesperrtes Ziel

COPY /source HTTP/1.1
Destination: http://example.com/locked-dest
If: <http://example.com/locked-dest>
    (<urn:uuid:dest-lock-token>)

Szenario 3: Bedingte Aktualisierung

PUT /resource HTTP/1.1
If: (["etag-value"])

Wenn der If-Header vorhanden ist, MUSS der Server alle Bedingungen auswerten, bevor die Methode ausgeführt wird. Schlägt die Auswertung fehl, MUSS der Server mit 412 Precondition Failed antworten.

10.5 Lock-Token Header​

Der Lock-Token-Header wird in der UNLOCK-Methode verwendet, um die zu entfernende Sperre (Lock) anzugeben.

Syntax​

Lock-Token: <uri>

Verwendung​

Ausschließlich für UNLOCK:

UNLOCK /resource HTTP/1.1
Host: example.com
Lock-Token: <urn:uuid:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>

HTTP/1.1 204 No Content

Unterschied zum If-Header​

  • Lock-Token: Wird ausschließlich bei UNLOCK verwendet, um die zu löschende Sperre anzugeben
  • If: Wird bei anderen Methoden verwendet, um Sperr-Tokens als Autorisierungsnachweis zu übermitteln

Der Lock-Token-Header MUSS bei UNLOCK-Anfragen vorhanden sein. Fehlt er, MUSS der Server mit 400 Bad Request antworten.

10.6 Overwrite Header​

Der Overwrite-Header gibt an, ob eine COPY- oder MOVE-Operation die Zielressource überschreiben soll.

Syntax​

Overwrite: T | F

Werte​

  • T (True): Zielressource überschreiben (Standardwert)
  • F (False): Nicht überschreiben; schlägt fehl, wenn das Ziel bereits existiert

Verhalten​

Overwrite: T:

  • Falls das Ziel existiert, wird es zunächst gelöscht
  • Anschließend wird die neue Ressource erstellt
  • Rückgabe: 204 No Content

Overwrite: F:

  • Falls das Ziel existiert, schlägt die Operation fehl
  • Rückgabe: 412 Precondition Failed
  • Keine Ressource wird verändert

Beispiele​

COPY /source.txt HTTP/1.1
Host: example.com
Destination: http://example.com/dest.txt
Overwrite: F

HTTP/1.1 412 Precondition Failed
COPY /source.txt HTTP/1.1
Host: example.com
Destination: http://example.com/dest.txt
Overwrite: T

HTTP/1.1 204 No Content

Wenn der Overwrite-Header nicht angegeben wird, MUSS der Server das Verhalten von Overwrite: T annehmen.

10.7 Timeout Request Header​

Der Timeout-Header wird in LOCK-Anfragen verwendet, um die gewünschte Sperr-Ablaufzeit (Lock Timeout) vorzuschlagen.

Syntax​

Timeout: Second-<seconds> | Infinite

Beispiele​

LOCK /resource HTTP/1.1
Host: example.com
Timeout: Second-3600

Timeout: Infinite

Timeout: Infinite, Second-604800, Second-86400

Serververhalten​

  • Kann abweichen: Der Server KANN den Vorschlag des Clients ignorieren und einen anderen Wert wählen
  • Tatsächlichen Wert zurückgeben: Die Antwort MUSS den vom Server gewählten Timeout-Wert enthalten
  • Sicherheitsbeschränkungen: Der Server KANN die maximale Sperrdauer begrenzen

Timeout in der Antwort​

<D:activelock>
  <D:timeout>Second-3600</D:timeout>
  ...
</D:activelock>

Der Wert Infinite bedeutet, dass die Sperre nicht automatisch abläuft. Server SOLLTEN jedoch aus Sicherheitsgründen eine maximale Sperrdauer durchsetzen.

Schnellreferenz: HTTP-Header​

HeaderVerwendete MethodenPflicht/OptionalBeschreibung
DAVOPTIONSAntwortUnterstützte Konformitätsstufen des Servers
DepthPROPFIND, COPY, LOCKOptionalTiefe der Operation
DestinationCOPY, MOVEPflichtZiel-URL
IfAlle MethodenOptionalBedingte Ausführung und Sperr-Token-Übermittlung
Lock-TokenUNLOCKPflichtZu entfernendes Sperr-Token
OverwriteCOPY, MOVEOptionalZiel überschreiben oder nicht
TimeoutLOCKOptionalVorgeschlagene Sperr-Ablaufzeit

Zusammenfassung: Kapitel 10 definiert die sieben spezialisierten HTTP-Header von WebDAV. Diese Header erweitern die Fähigkeiten von HTTP/1.1 und unterstützen Tiefenoperationen (Depth), Ressourcenoperationen (Destination, Overwrite), Sperrverwaltung (Lock-Token, Timeout) sowie bedingte Ausführung (If). Die korrekte Verwendung dieser Header ist für die Implementierung zuverlässiger WebDAV-Clients und -Server unerlässlich.

12. Use of HTTP Status Codes (Verwendung von HTTP-Statuscodes)​

Diese HTTP-Codes werden nicht neu definiert, aber ihre Verwendung wird durch WebDAV-Methoden und -Anforderungen etwas erweitert. Im Allgemeinen können viele HTTP-Statuscodes als Antwort auf jede Anfrage verwendet werden, nicht nur in den in diesem Dokument beschriebenen Fällen. Beachten Sie auch, dass WebDAV-Server bekanntermaßen Umleitungsantworten der Stufe 300 verwenden (und frühe Interoperabilitätstests ergaben, dass Clients nicht darauf vorbereitet waren, diese Antworten zu sehen). Eine Antwort der Stufe 300 DARF NICHT verwendet werden, wenn der Server als Antwort auf die Anfrage eine neue Ressource erstellt hat.

12.1. 412 Precondition Failed (412 Vorbedingung fehlgeschlagen)​

Jede Anfrage kann einen in HTTP definierten bedingten Header (If-Match, If-Modified-Since usw.) oder die in dieser Spezifikation definierten bedingten Header "If" oder "Overwrite" enthalten. Wenn der Server einen bedingten Header auswertet und diese Bedingung nicht erfüllt ist, dann MUSS dieser Fehlercode zurückgegeben werden. Andererseits, wenn der Client keinen bedingten Header in die Anfrage aufgenommen hat, dann DARF der Server diesen Statuscode NICHT verwenden.

12.2. 414 Request-URI Too Long (414 Anfrage-URI zu lang)​

Dieser Statuscode wird in HTTP 1.1 nur für Request-URIs verwendet, nicht für URIs an anderen Stellen.

13. Multi-Status Response (Multi-Status-Antwort)​

Eine Multi-Status-Antwort übermittelt Informationen über mehrere Ressourcen in Situationen, in denen mehrere Statuscodes angemessen sein könnten. Der Standard-Multi-Status-Antwortkörper ist eine text/xml- oder application/xml-HTTP-Entität mit einem 'multistatus'-Wurzelelement. Weitere Elemente enthalten 200-, 300-, 400- und 500-Serien-Statuscodes, die während des Methodenaufrufs generiert wurden. Statuscodes der 100-Serie SOLLTEN NICHT in einem 'response'-XML-Element aufgezeichnet werden.

Obwohl '207' als Gesamtantwortstatuscode verwendet wird, muss der Empfänger den Inhalt des multistatus-Antwortkörpers konsultieren, um weitere Informationen über den Erfolg oder Misserfolg der Methodenausführung zu erhalten. Die Antwort KANN in Erfolgs-, Teilerfolgs- und auch Fehlersituationen verwendet werden.

Das 'multistatus'-Wurzelelement enthält null oder mehr 'response'-Elemente in beliebiger Reihenfolge, jedes mit Informationen über eine einzelne Ressource. Jedes 'response'-Element MUSS ein 'href'-Element haben, um die Ressource zu identifizieren.

Eine Multi-Status-Antwort verwendet eines von zwei unterschiedlichen Formaten zur Darstellung des Status:

  1. Ein 'status'-Element als Kind des 'response'-Elements zeigt den Status der Nachrichtenausführung für die identifizierte Ressource als Ganzes an (siehe beispielsweise Abschnitt 9.6.2). Einige Methodendefinitionen bieten Informationen über spezifische Statuscodes, auf die Clients in einer Antwort vorbereitet sein sollten. Clients MÜSSEN jedoch in der Lage sein, andere Statuscodes zu verarbeiten, unter Verwendung der allgemeinen Regeln, die in Abschnitt 10 von [RFC2616] definiert sind.

  2. Für PROPFIND und PROPPATCH wurde das Format unter Verwendung des 'propstat'-Elements anstelle von 'status' erweitert, um Informationen über einzelne Eigenschaften einer Ressource bereitzustellen. Dieses Format ist spezifisch für PROPFIND und PROPPATCH und wird in den Abschnitten 9.1 und 9.2 ausführlich beschrieben.

13.1. Response Headers (Antwort-Header)​

HTTP definiert den Location-Header, um eine bevorzugte URL für die Ressource anzugeben, die im Request-URI adressiert wurde (z.B. als Antwort auf erfolgreiche PUT-Anfragen oder in Umleitungsantworten). Die Verwendung dieses Headers erzeugt jedoch Mehrdeutigkeit, wenn URLs im Körper der Antwort vorhanden sind, wie bei Multi-Status. Daher ist die Verwendung des Location-Headers mit der Multi-Status-Antwort absichtlich undefiniert.

13.2. Handling Redirected Child Resources (Umgang mit umgeleiteten Kindressourcen)​

Umleitungsantworten (300-303, 305 und 307), die in HTTP 1.1 definiert sind, nehmen normalerweise einen Location-Header, um den neuen URI für die einzelne vom Request-URI umgeleitete Ressource anzugeben. Multi-Status-Antworten enthalten viele Ressourcenadressen, aber die ursprüngliche Definition in [RFC2518] hatte keinen Platz für den Server, um den neuen URI für umgeleitete Ressourcen bereitzustellen. Diese Spezifikation definiert ein 'location'-Element für diese Information (siehe Abschnitt 14.9). Server MÜSSEN dieses neue Element bei Umleitungsantworten in Multi-Status verwenden.

Clients, die auf umgeleitete Ressourcen in Multi-Status stoßen, DÜRFEN NICHT darauf vertrauen, dass das 'location'-Element mit einem neuen URI vorhanden ist. Wenn das Element nicht vorhanden ist, KANN der Client die Anfrage an die einzelne umgeleitete Ressource erneut stellen, da die Antwort auf diese Anfrage mit einem Location-Header umgeleitet werden kann, der den neuen URI enthält.

13.3. Internal Status Codes (Interne Statuscodes)​

Die Abschnitte 9.2.1, 9.1.2, 9.6.1, 9.8.3 und 9.9.2 definieren verschiedene Statuscodes, die in Multi-Status-Antworten verwendet werden. Diese Spezifikation definiert nicht die Bedeutung anderer Statuscodes, die in diesen Antworten erscheinen könnten.

16. Precondition/Postcondition XML Elements (Vorbedingung/Nachbedingung XML-Elemente)​

Wie in Abschnitt 8.7 eingeführt, können zusätzliche Informationen über Fehlerbedingungen im Körper vieler Statusantworten enthalten sein. Dieser Abschnitt stellt Anforderungen an die Verwendung des Fehlerköper-Mechanismus und führt eine Reihe von Vorbedingungen und Nachbedingungen ein.

Eine "Vorbedingung (precondition)" einer Methode beschreibt den Zustand des Servers, der wahr sein muss, damit diese Methode ausgeführt werden kann. Eine "Nachbedingung (postcondition)" einer Methode beschreibt den Zustand des Servers, der wahr sein muss, nachdem diese Methode abgeschlossen wurde.

Jede Vorbedingung und Nachbedingung hat ein eindeutiges XML-Element, das mit ihr verbunden ist. In einer 207 Multi-Status-Antwort MUSS das XML-Element innerhalb eines 'error'-Elements im entsprechenden 'propstat- oder 'response'-Element erscheinen, je nachdem, ob die Bedingung auf eine oder mehrere Eigenschaften oder auf die Ressource als Ganzes zutrifft. In allen anderen Fehlerantworten, bei denen der 'error'-Körper dieser Spezifikation verwendet wird, MUSS das Vorbedingung/Nachbedingung-XML-Element als Kind eines 'error'-Elements der obersten Ebene im Antwortkörper zurückgegeben werden, sofern nicht anders durch die Anfrage verhandelt, zusammen mit einem entsprechenden Antwortstatus. Die häufigsten Antwortstatuscodes sind 403 (Forbidden), wenn die Anfrage nicht wiederholt werden sollte, weil sie immer fehlschlagen wird, und 409 (Conflict), wenn erwartet wird, dass der Benutzer den Konflikt möglicherweise lösen und die Anfrage erneut senden kann. Das 'error'-Element KANN Kindelemente mit spezifischen Fehlerinformationen enthalten und KANN mit beliebigen benutzerdefinierten Kindelementen erweitert werden.

Dieser Mechanismus ersetzt nicht die Verwendung eines korrekten numerischen Statuscodes, wie hier oder in HTTP definiert, da der Client immer in der Lage sein muss, eine vernünftige Vorgehensweise nur auf der Grundlage des numerischen Codes zu wählen. Es beseitigt jedoch die Notwendigkeit, neue numerische Codes zu definieren. Die neuen maschinenlesbaren Codes, die für diesen Zweck verwendet werden, sind XML-Elemente, die als Vorbedingungen und Nachbedingungen klassifiziert sind, sodass natürlich jede Gruppe, die einen neuen Bedingungscode definiert, ihren eigenen Namespace verwenden kann. Wie immer ist der Namespace "DAV:" für die Verwendung durch IETF-beauftragte WebDAV-Arbeitsgruppen reserviert.

Ein Server, der diese Spezifikation unterstützt, SOLLTE den XML-Fehler verwenden, wenn eine in diesem Dokument definierte Vorbedingung oder Nachbedingung verletzt wird. Für Fehlerbedingungen, die in diesem Dokument nicht spezifiziert sind, KANN der Server einfach einen geeigneten numerischen Status wählen und den Antwortkörper leer lassen. Ein Server KANN jedoch stattdessen einen benutzerdefinierten Bedingungscode und anderen unterstützenden Text verwenden, da selbst wenn Clients Bedingungscodes nicht automatisch erkennen, sie bei Interoperabilitätstests und Debugging sehr nützlich sein können.

Beispiel - Antwort mit Vorbedingungscode:

HTTP/1.1 423 Locked
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:error xmlns:D="DAV:">
  &lt;D:lock-token-submitted>
    &lt;D:href>/workspace/webdav/&lt;D:href>
  &lt;D:lock-token-submitted>
&lt;D:error>

In diesem Beispiel versuchte ein Client, der sich einer Tiefe-Unendlich-Sperre auf der übergeordneten Sammlung "/workspace/webdav/" nicht bewusst war, das Sammlungsmitglied "/workspace/webdav/proposal.doc" zu ändern.

Einige andere nützliche Vorbedingungen und Nachbedingungen wurden in anderen Spezifikationen definiert, die WebDAV erweitern, wie [RFC3744] (siehe insbesondere Abschnitt 7.1.1), [RFC3253] und [RFC3648].

Alle diese Elemente befinden sich im Namespace "DAV:". Sofern nicht anders angegeben, ist der Inhalt des XML-Elements jeder Bedingung als leer definiert.

lock-token-matches-request-uri​

Name: lock-token-matches-request-uri

Verwendung mit (Use with): 409 Conflict

Zweck (Purpose): (Vorbedingung) -- Eine Anfrage kann einen Lock-Token-Header enthalten, um eine Sperre für die UNLOCK-Methode zu identifizieren. Wenn jedoch die Request-URI nicht in den Geltungsbereich der durch das Token identifizierten Sperre fällt, SOLLTE der Server diesen Fehler verwenden. Die Sperre kann einen Geltungsbereich haben, der die Request-URI nicht einschließt, oder die Sperre könnte verschwunden sein, oder das Token könnte ungültig sein.

lock-token-submitted​

Name: lock-token-submitted (Vorbedingung)

Verwendung mit (Use with): 423 Locked

Zweck (Purpose): Die Anfrage konnte nicht erfolgreich sein, weil ein Sperr-Token hätte eingereicht werden müssen. Dieses Element MUSS, falls vorhanden, mindestens eine URL einer gesperrten Ressource enthalten, die die Anfrage verhindert hat. In Fällen von MOVE, COPY und DELETE, bei denen Sammlungssperren beteiligt sind, kann es für den Client schwierig sein, herauszufinden, welche gesperrte Ressource die Anfrage zum Scheitern gebracht hat -- aber der Server ist nur dafür verantwortlich, eine solche gesperrte Ressource zurückzugeben. Der Server KANN jede gesperrte Ressource zurückgeben, die den Erfolg der Anfrage verhindert hat, wenn er sie alle kennt.

&lt;!ELEMENT lock-token-submitted (href+) >

no-conflicting-lock​

Name: no-conflicting-lock (Vorbedingung)

Verwendung mit (Use with): Typischerweise 423 Locked

Zweck (Purpose): Eine LOCK-Anfrage ist aufgrund des Vorhandenseins einer bereits bestehenden konfliktierenden Sperre fehlgeschlagen. Beachten Sie, dass eine Sperre in Konflikt sein kann, obwohl die Ressource, an die die Anfrage gerichtet war, nur indirekt gesperrt ist. In diesem Fall kann der Vorbedingungscode verwendet werden, um den Client über die Ressource zu informieren, die die Wurzel der konfliktierenden Sperre ist, wodurch eine separate Suche nach der Eigenschaft "lockdiscovery" vermieden wird.

&lt;!ELEMENT no-conflicting-lock (href)* >

no-external-entities​

Name: no-external-entities

Verwendung mit (Use with): 403 Forbidden

Zweck (Purpose): (Vorbedingung) -- Wenn der Server eine Client-Anfrage ablehnt, weil der Anfragekörper eine externe Entität enthält, SOLLTE der Server diesen Fehler verwenden.

preserved-live-properties​

Name: preserved-live-properties

Verwendung mit (Use with): 409 Conflict

Zweck (Purpose): (Nachbedingung) -- Der Server hat eine ansonsten gültige MOVE- oder COPY-Anfrage erhalten, kann aber die Live-Eigenschaften mit demselben Verhalten am Ziel nicht aufrechterhalten. Es kann sein, dass der Server nur einige Live-Eigenschaften in einigen Teilen des Repositorys unterstützt oder einfach einen internen Fehler hat.

propfind-finite-depth​

Name: propfind-finite-depth

Verwendung mit (Use with): 403 Forbidden

Zweck (Purpose): (Vorbedingung) -- Dieser Server erlaubt keine PROPFIND-Anfragen mit unendlicher Tiefe für Sammlungen.

cannot-modify-protected-property​

Name: cannot-modify-protected-property

Verwendung mit (Use with): 403 Forbidden

Zweck (Purpose): (Vorbedingung) -- Der Client hat versucht, eine geschützte Eigenschaft in einem PROPPATCH zu setzen (wie DAV:getetag). Siehe auch [RFC3253], Abschnitt 3.12.

17. XML Extensibility in DAV (XML-Erweiterbarkeit in DAV)​

Die XML-Namespace-Erweiterung ([REC-XML-NAMES]) wird in dieser Spezifikation verwendet, um das Hinzufügen neuer XML-Elemente zu ermöglichen, ohne dass Kollisionen mit anderen Elementnamen befürchtet werden müssen. Obwohl WebDAV-Anfrage- und Antwortkörper durch beliebige XML-Elemente erweitert werden können, die vom Nachrichtenempfänger ignoriert werden können, SOLLTE ein XML-Element im Namespace "DAV:" NICHT im Anfrage- oder Antwortkörper verwendet werden, es sei denn, dieses XML-Element ist in einem von einer WebDAV-Arbeitsgruppe überprüften IETF RFC explizit definiert.

Damit WebDAV sowohl erweiterbar als auch abwärtskompatibel ist, müssen sowohl Clients als auch Server wissen, wie sie sich verhalten sollen, wenn unerwartete oder nicht erkannte Befehlserweiterungen empfangen werden. Für die XML-Verarbeitung bedeutet dies, dass Clients und Server empfangene XML-Dokumente so verarbeiten MÜSSEN, als ob unerwartete Elemente und Attribute (und alle Kinder nicht erkannter Elemente) nicht vorhanden wären. Ein unerwartetes Element oder Attribut umfasst eines, das in einem anderen Kontext verwendet werden kann, hier aber nicht erwartet wird. Das Ignorieren solcher Elemente für Verarbeitungszwecke kann natürlich mit dem Protokollieren aller Informationen oder der Präsentation zum Debuggen konsistent sein.

Diese Einschränkung gilt auch für die Verarbeitung von DAV-Eigenschaftswerten durch Clients, wobei unerwartete XML-Elemente ignoriert werden SOLLTEN, es sei denn, das Schema der Eigenschaft erklärt etwas anderes.

Diese Einschränkung gilt nicht für das Setzen toter DAV-Eigenschaften auf dem Server, wo der Server alle XML-Elemente aufzeichnen MUSS.

Darüber hinaus gilt diese Einschränkung nicht für die Verwendung von XML, bei der XML zufällig der Inhaltstyp des Entitätskörpers ist, beispielsweise wenn es als Körper eines PUT verwendet wird.

Verarbeitungsanweisungen in XML SOLLTEN von Empfängern ignoriert werden. Daher SOLLTEN Spezifikationen, die WebDAV erweitern, KEINE Verarbeitungsanweisungen verwenden, um normatives Verhalten zu definieren.

Für alle in dieser Spezifikation definierten XML-Elemente sind XML-DTD-Fragmente enthalten. Korrektes XML wird jedoch aufgrund der Namespace-Verwendung und Erweiterungsregeln nach keiner DTD gültig sein. Insbesondere:

  • Elemente (aus dieser Spezifikation) befinden sich im Namespace "DAV:",
  • Die Elementreihenfolge ist irrelevant, sofern nicht anders angegeben,
  • Erweiterungsattribute KÖNNEN hinzugefügt werden,
  • Für Elementtypdefinitionen von "ANY" definiert die normative Textdefinition für dieses Element, was darin enthalten sein kann und was das bedeutet.
  • Für Elementtypdefinitionen von "#PCDATA" DÜRFEN Erweiterungselemente NICHT hinzugefügt werden.
  • Für andere Elementtypdefinitionen, einschließlich "EMPTY", KÖNNEN Erweiterungselemente hinzugefügt werden.

Beachten Sie, dass dies bedeutet, dass Elemente, die Elemente enthalten, nicht erweitert werden können, um Text zu enthalten, und umgekehrt.

Mit durch die obigen Regeln gelockerten DTD-Validierung sind die von den DTD-Fragmenten beschriebenen Einschränkungen normativ (siehe z.B. Anhang A). Ein Empfänger einer WebDAV-Nachricht mit einem XML-Körper DARF das XML-Dokument NICHT gemäß einer fest codierten oder dynamisch deklarierten DTD validieren.

Beachten Sie, dass dieser Abschnitt abwärtskompatible Erweiterbarkeitsregeln beschreibt. Es kann auch Zeiten geben, in denen eine Erweiterung so konzipiert ist, dass sie nicht abwärtskompatibel ist, beispielsweise die Definition einer Erweiterung, die ein in diesem Dokument definiertes XML-Element wiederverwendet, aber eines der von den DTDs in dieser Spezifikation geforderten Kindelemente weglässt.

18. DAV Compliance Classes (DAV-Compliance-Klassen)​

Eine DAV-konforme Ressource kann mehrere Compliance-Klassen anzeigen. Ein Client kann die Compliance-Klassen einer Ressource ermitteln, indem er OPTIONS auf der Ressource ausführt und den zurückgegebenen "DAV"-Header untersucht. Beachten Sie insbesondere, dass von Ressourcen und nicht von Servern gesprochen wird, die konform sind. Das liegt daran, dass theoretisch einige Ressourcen auf einem Server unterschiedliche Funktionssets unterstützen könnten. Beispielsweise könnte ein Server ein Sub-Repository haben, in dem eine erweiterte Funktion wie Versionierung unterstützt wird, selbst wenn diese Funktion nicht auf allen Sub-Repositories unterstützt wird.

Da dieses Dokument Erweiterungen des HTTP/1.1-Protokolls beschreibt, MÜSSEN mindestens alle DAV-konformen Ressourcen, Clients und Proxies konform zu [RFC2616] sein.

Eine Ressource, die Klasse 2 oder Klasse 3 konform ist, muss auch Klasse 1 konform sein.

18.1. Class 1 (Klasse 1)​

Eine Klasse-1-konforme Ressource MUSS alle "MUSS"-Anforderungen in allen Abschnitten dieses Dokuments erfüllen.

Klasse-1-konforme Ressourcen MÜSSEN mindestens den Wert "1" im DAV-Header bei allen Antworten auf die OPTIONS-Methode zurückgeben.

18.2. Class 2 (Klasse 2)​

Eine Klasse-2-konforme Ressource MUSS alle Klasse-1-Anforderungen erfüllen und die LOCK-Methode, die DAV:supportedlock-Eigenschaft, die DAV:lockdiscovery-Eigenschaft, den Time-Out-Antwort-Header und den Lock-Token-Anfrage-Header unterstützen. Eine Klasse-2-konforme Ressource SOLLTE auch den Timeout-Anfrage-Header und das 'owner'-XML-Element unterstützen.

Klasse-2-konforme Ressourcen MÜSSEN mindestens die Werte "1" und "2" im DAV-Header bei allen Antworten auf die OPTIONS-Methode zurückgeben.

18.3. Class 3 (Klasse 3)​

Eine Ressource kann explizit ihre Unterstützung für die in diesem Dokument vorgenommenen Überarbeitungen von [RFC2518] ankündigen. Klasse 1 MUSS ebenfalls unterstützt werden. Klasse 2 KANN unterstützt werden. Das Ankündigen der Klasse-3-Unterstützung zusätzlich zu Klasse 1 und 2 bedeutet, dass der Server alle Anforderungen in dieser Spezifikation unterstützt. Das Ankündigen von Klasse-3- und Klasse-1-Unterstützung, aber nicht Klasse 2, bedeutet, dass der Server alle Anforderungen in dieser Spezifikation unterstützt, mit Ausnahme möglicherweise derjenigen, die Sperrunterstützung betreffen.

Beispiel:

DAV: 1, 3

19. Internationalization Considerations (Internationalisierungsüberlegungen)​

Im Bereich der Internationalisierung entspricht diese Spezifikation der IETF-Zeichensatzrichtlinie [RFC2277]. In dieser Spezifikation können von Menschen lesbare Felder entweder im Wert einer Eigenschaft oder in einer Fehlermeldung gefunden werden, die im Antwortkörper zurückgegeben wird. In beiden Fällen wird der von Menschen lesbare Inhalt unter Verwendung von XML codiert, das explizite Bestimmungen für Zeichensatz-Tagging und -Codierung hat und erfordert, dass XML-Prozessoren XML-Elemente lesen, die mindestens unter Verwendung der UTF-8 [RFC3629] und UTF-16 [RFC2781] Codierungen der ISO 10646-Mehrsprachen-Ebene codiert sind. Die XML-Beispiele in dieser Spezifikation demonstrieren die Verwendung des charset-Parameters des Content-Type-Headers (definiert in [RFC3023]) sowie XML-Charset-Deklarationen.

XML bietet auch eine Sprach-Tagging-Fähigkeit zur Angabe der Sprache des Inhalts eines bestimmten XML-Elements. Das Attribut "xml:lang" erscheint auf einem XML-Element, um die Sprache seines Inhalts und seiner Attribute zu identifizieren. Siehe [REC-XML] für Definitionen von Werten und Geltungsbereich.

WebDAV-Anwendungen MÜSSEN das Zeichensatz-Tagging, die Zeichensatzcodierung und die Sprach-Tagging-Funktionalität der XML-Spezifikation unterstützen. Implementierern von WebDAV-Anwendungen wird dringend empfohlen, "XML Media Types" [RFC3023] zu lesen, um Anweisungen zu erhalten, welcher MIME-Medientyp für den XML-Transport zu verwenden ist und zur Verwendung des charset-Parameters des Content-Type-Headers.

In dieser Spezifikation verwendete Namen fallen in vier Kategorien: Namen von Protokollelementen wie Methoden und Headern, Namen von XML-Elementen, Namen von Eigenschaften und Namen von Bedingungen. Die Benennung von Protokollelementen folgt dem Präzedenzfall von HTTP und verwendet englische Namen, die in US-ASCII codiert sind, für Methoden und Header. Da diese Protokollelemente für Benutzer nicht sichtbar sind und einfach lange Token-Identifikatoren sind, müssen sie mehrere Sprachen nicht unterstützen. Ebenso sind die Namen der in dieser Spezifikation verwendeten XML-Elemente für den Benutzer nicht sichtbar und müssen daher mehrere Sprachen nicht unterstützen.

WebDAV-Eigenschaftsnamen sind qualifizierte XML-Namen (Paare aus XML-Namespace-Namen und lokalem Namen). Obwohl einige Anwendungen (z.B. ein generischer Eigenschaftsbetrachter) Eigenschaftsnamen direkt ihren Benutzern anzeigen, wird erwartet, dass die typische Anwendung einen festen Satz von Eigenschaften verwendet und eine Zuordnung vom Eigenschaftsnamen und Namespace zu einem von Menschen lesbaren Feld bereitstellt, wenn der Eigenschaftsname einem Benutzer angezeigt wird. Nur in dem Fall, in dem der Satz von Eigenschaften nicht im Voraus bekannt ist, muss eine Anwendung einem Benutzer einen Eigenschaftsnamen anzeigen. Wir empfehlen, dass Anwendungen wo immer möglich von Menschen lesbare Eigenschaftsnamen bereitstellen.

Für die Fehlerberichterstattung folgen wir der Konvention der HTTP/1.1-Statuscodes, einschließlich einer kurzen englischen Beschreibung des Codes bei jedem Statuscode (z.B. 423 (Locked)). Während die Möglichkeit besteht, dass ein schlecht gestalteter Benutzeragent diese Nachricht einem Benutzer anzeigt, werden internationalisierte Anwendungen diese Nachricht ignorieren und eine angemessene Nachricht in der Sprache und dem Zeichensatz des Benutzers anzeigen.

Da die Interoperation von Clients und Servern keine Locale-Informationen erfordert, spezifiziert diese Spezifikation keinen Mechanismus für die Übertragung dieser Informationen.

20. Security Considerations (Sicherheitsüberlegungen)​

Dieser Abschnitt wird bereitgestellt, um Fragen bezüglich Sicherheitsauswirkungen zu detaillieren, derer sich WebDAV-Anwendungen bewusst sein müssen.

Alle Sicherheitsüberlegungen von HTTP/1.1 (besprochen in [RFC2616]) und XML (besprochen in [RFC3023]) gelten auch für WebDAV. Darüber hinaus erfordern die Sicherheitsrisiken, die dem Remote-Authoring innewohnen, eine stärkere Authentifizierungstechnologie, führen mehrere neue Datenschutzbedenken ein und können die Gefahren durch schlechtes Serverdesign erhöhen. Diese Probleme werden im Folgenden detailliert beschrieben.

20.1. Authentication of Clients (Authentifizierung von Clients)​

Aufgrund ihrer Betonung auf Authoring müssen WebDAV-Server Authentifizierungstechnologie verwenden, um nicht nur den Zugriff auf eine Netzwerkressource zu schützen, sondern auch die Integrität der Ressource. Darüber hinaus erfordert die Einführung von Sperrfunktionalität Unterstützung für die Authentifizierung.

Ein Passwort, das im Klartext über einen unsicheren Kanal gesendet wird, ist ein unzureichendes Mittel zum Schutz der Zugänglichkeit und Integrität einer Ressource, da das Passwort abgefangen werden kann. Da die Basisauthentifizierung für HTTP/1.1 im Wesentlichen eine Klartextübertragung eines Passworts durchführt, DARF die Basisauthentifizierung NICHT verwendet werden, um einen WebDAV-Client bei einem Server zu authentifizieren, es sei denn, die Verbindung ist sicher. Darüber hinaus DARF ein WebDAV-Server KEINE Basisauthentifizierungs-Challenge in einem WWW-Authenticate-Header senden, es sei denn, die Verbindung ist sicher. Ein Beispiel für eine sichere Verbindung wäre eine Transport Layer Security (TLS)-Verbindung, die eine starke Cipher-Suite und Serverauthentifizierung verwendet.

WebDAV-Anwendungen MÜSSEN das Digest-Authentifizierungsschema [RFC2617] unterstützen. Da die Digest-Authentifizierung überprüft, dass beide Parteien einer Kommunikation ein gemeinsames Geheimnis, ein Passwort, kennen, ohne dieses Geheimnis im Klartext senden zu müssen, vermeidet die Digest-Authentifizierung die Sicherheitsprobleme, die der Basisauthentifizierung innewohnen, und bietet gleichzeitig ein Authentifizierungsniveau, das in einer Vielzahl von Szenarien nützlich ist.

20.2. Denial of Service (Dienstverweigerung)​

Denial-of-Service-Angriffe sind für WebDAV-Server von besonderer Bedeutung. WebDAV plus HTTP ermöglicht Denial-of-Service-Angriffe auf jeden Teil der Systemressourcen.

  • Der zugrunde liegende Speicher kann angegriffen werden, indem extrem große Dateien mit PUT übertragen werden.
  • Die Anforderung rekursiver Operationen auf großen Sammlungen kann die Verarbeitungszeit angreifen.
  • Das Erstellen mehrerer Pipeline-Anfragen über mehrere Verbindungen kann Netzwerkverbindungen angreifen.

WebDAV-Server müssen sich der Möglichkeit eines Denial-of-Service-Angriffs auf allen Ebenen bewusst sein. Die angemessene Reaktion auf einen solchen Angriff KANN sein, einfach die Verbindung zu trennen. Oder, wenn der Server in der Lage ist, eine Antwort zu geben, KANN der Server eine 400-Level-Statusanfrage wie 400 (Bad Request) verwenden und angeben, warum die Anfrage abgelehnt wurde (eine 500-Level-Statusantwort würde darauf hinweisen, dass das Problem beim Server liegt, während unbeabsichtigte DoS-Angriffe etwas sind, das der Client beheben kann).

20.3. Security through Obscurity (Sicherheit durch Verschleierung)​

WebDAV bietet über die PROPFIND-Methode einen Mechanismus zum Auflisten der Mitgliedsressourcen einer Sammlung. Dies verringert die Wirksamkeit von Sicherheits- oder Datenschutztechniken erheblich, die nur auf der Schwierigkeit beruhen, die Namen von Netzwerkressourcen zu entdecken. Benutzern von WebDAV-Servern wird empfohlen, Zugriffskontrolltechniken zu verwenden, um unerwünschten Zugriff auf Ressourcen zu verhindern, anstatt sich auf die relative Verschleierung ihrer Ressourcennamen zu verlassen.

20.4. Privacy Issues Connected to Locks (Datenschutzprobleme im Zusammenhang mit Sperren)​

Beim Senden einer Sperranfrage kann ein Benutzeragent auch ein 'owner' XML-Feld senden, das Kontaktinformationen für die Person bereitstellt, die die Sperre erwirbt (für die Fälle, in denen eine Person und nicht ein Roboter die Sperre erwirbt). Diese Kontaktinformationen werden in einer DAV:lockdiscovery-Eigenschaft der Ressource gespeichert und können von anderen Mitarbeitern verwendet werden, um Verhandlungen über den Zugriff auf die Ressource zu beginnen. In vielen Fällen können diese Kontaktinformationen jedoch sehr privat sein und sollten nicht weit verbreitet werden. Server SOLLTEN den Lesezugriff auf die DAV:lockdiscovery-Eigenschaft angemessen einschränken. Darüber hinaus SOLLTEN Benutzeragenten die Kontrolle darüber bieten, ob Kontaktinformationen überhaupt gesendet werden, und wenn Kontaktinformationen gesendet werden, die Kontrolle darüber, welche Informationen genau gesendet werden.

20.5. Privacy Issues Connected to Properties (Datenschutzprobleme im Zusammenhang mit Eigenschaften)​

Da Eigenschaftswerte typischerweise verwendet werden, um Informationen wie den Autor eines Dokuments zu halten, besteht die Möglichkeit, dass Datenschutzbedenken aufgrund des weitreichenden Zugriffs auf die Eigenschaftsdaten einer Ressource entstehen könnten. Um das Risiko einer versehentlichen Freigabe privater Informationen über Eigenschaften zu verringern, werden Server ermutigt, Zugriffskontrollmechanismen zu entwickeln, die den Lesezugriff auf den Ressourcenkörper und den Lesezugriff auf die Eigenschaften der Ressource trennen. Dies ermöglicht es einem Benutzer, die Verbreitung seiner Eigenschaftsdaten zu kontrollieren, ohne den Zugriff auf den Inhalt der Ressource übermäßig einzuschränken.

20.6. Implications of XML Entities (Auswirkungen von XML-Entitäten)​

XML unterstützt eine Funktion, die als "externe Entitäten" bekannt ist und in Abschnitt 4.2.2 von [REC-XML] definiert ist, die einen XML-Prozessor anweist, zusätzliches XML abzurufen und einzuschließen. Eine externe XML-Entität kann verwendet werden, um die mit einem XML-Dokument verbundene Dokumenttyp-Deklaration (DTD) anzuhängen oder zu ändern. Eine externe XML-Entität kann auch verwendet werden, um XML innerhalb des Inhalts eines XML-Dokuments einzuschließen. Für nicht validierendes XML, wie das in dieser Spezifikation verwendete XML, ist das Einschließen einer externen XML-Entität von XML nicht erforderlich. XML gibt jedoch an, dass ein XML-Prozessor nach eigenem Ermessen die externe XML-Entität einschließen kann.

Externe XML-Entitäten haben keine inhärente Vertrauenswürdigkeit und unterliegen allen Angriffen, die für jede HTTP GET-Anfrage endemisch sind. Darüber hinaus ist es möglich, dass eine externe XML-Entität die DTD modifiziert und somit die endgültige Form eines XML-Dokuments beeinflusst, im schlimmsten Fall seine Semantik erheblich ändert oder den XML-Prozessor den in [RFC3023] diskutierten Sicherheitsrisiken aussetzt. Daher müssen sich Implementierer bewusst sein, dass externe XML-Entitäten als nicht vertrauenswürdig behandelt werden sollten. Wenn ein Server sich entscheidet, externe XML-Entitäten nicht zu verarbeiten, SOLLTE er auf Anfragen, die externe Entitäten enthalten, mit dem Bedingungscode 'no-external-entities' antworten.

Es besteht auch das Skalierbarkeitrisiko, das eine weit verbreitete Anwendung begleiten würde, die externe XML-Entitäten verwendet. In dieser Situation ist es möglich, dass es erhebliche Zahlen von Anfragen für eine externe XML-Entität gibt, die potenziell jeden Server überlasten, der Anfragen für die Ressource mit der externen XML-Entität verarbeitet.

Darüber hinaus besteht auch ein Risiko basierend auf der Bewertung von "internen Entitäten", wie in Abschnitt 4.2.2 von [REC-XML] definiert. Eine kleine, sorgfältig gestaltete Anfrage mit verschachtelten internen Entitäten kann enorme Mengen an Speicher und/oder Verarbeitungszeit zur Verarbeitung erfordern. Server-Implementierer sollten sich dieses Risikos bewusst sein und ihre XML-Parser so konfigurieren, dass solche Anfragen so früh wie möglich erkannt und abgelehnt werden können.

20.7. Risks Connected with Lock Tokens (Risiken im Zusammenhang mit Sperr-Tokens)​

Diese Spezifikation ermutigt die Verwendung von "A Universally Unique Identifier (UUID) URN Namespace" ([RFC4122]) für Sperr-Tokens (Abschnitt 6.5), um deren Einzigartigkeit über Raum und Zeit zu garantieren. Version 1 UUIDs (definiert in Abschnitt 4) KÖNNEN ein "node"-Feld enthalten, das "aus einer IEEE 802 MAC-Adresse besteht, normalerweise die Hostadresse. Für Systeme mit mehreren IEEE-Adressen kann jede verfügbare verwendet werden". Da ein WebDAV-Server während seiner Lebensdauer viele Sperren ausgibt, besteht die Implikation darin, dass er möglicherweise auch seine IEEE 802-Adresse öffentlich preisgibt.

Mit der Offenlegung von IEEE 802-Adressen sind mehrere Risiken verbunden. Unter Verwendung der IEEE 802-Adresse:

  • Es ist möglich, die Bewegung von Hardware von Subnetz zu Subnetz zu verfolgen.
  • Es kann möglich sein, den Hersteller der Hardware zu identifizieren, auf der ein WebDAV-Server läuft.
  • Es kann möglich sein, die Anzahl jedes Computertyps zu bestimmen, auf dem WebDAV läuft.

Dieses Risiko gilt nur für hostadressbasierte UUID-Versionen. Abschnitt 4 von [RFC4122] beschreibt mehrere andere Mechanismen zum Generieren von UUIDs, die die Hostadresse nicht einbeziehen und daher nicht von diesem Risiko betroffen sind.

20.8. Hosting Malicious Content (Hosting bösartiger Inhalte)​

HTTP hat die Fähigkeit, Programme zu hosten, die auf Client-Maschinen ausgeführt werden. Diese Programme können viele Formen annehmen, einschließlich Web-Skripte, ausführbare Dateien, Plug-in-Module und Makros in Dokumenten. WebDAV ändert keine der Sicherheitsbedenken rund um diese Programme, doch wird WebDAV oft in Kontexten verwendet, in denen eine breite Palette von Benutzern Dokumente auf einem Server veröffentlichen kann. Der Server hat möglicherweise keine enge Vertrauensbeziehung zum Autor, der das Dokument veröffentlicht. Server, die es Clients ermöglichen, beliebige Inhalte zu veröffentlichen, können nützlicherweise Vorsichtsmaßnahmen implementieren, um zu überprüfen, dass auf dem Server veröffentlichte Inhalte für andere Clients nicht schädlich sind. Server könnten dies durch Techniken wie die Einschränkung der Arten von Inhalten, die veröffentlicht werden dürfen, und das Ausführen von Viren- und Malware-Erkennungssoftware auf veröffentlichten Inhalten tun. Server können das Risiko auch mindern, indem sie angemessene Zugriffsbeschränkungen und Authentifizierung von Benutzern haben, die Inhalte auf dem Server veröffentlichen dürfen.

21. IANA Considerations (IANA-Überlegungen)​

21.1. New URI Schemes (Neue URI-Schemas)​

Diese Spezifikation definiert zwei URI-Schemas:

  1. das "opaquelocktoken"-Schema, das in Anhang C definiert ist, und

  2. das "DAV" URI-Schema, das historisch in [RFC2518] verwendet wurde, um WebDAV-Eigenschaftsnamen und XML-Elementnamen eindeutig zu machen und das weiterhin für diesen Zweck in dieser Spezifikation und anderen WebDAV erweiternden Spezifikationen verwendet wird. Die Erstellung von Identifikatoren im "DAV:"-Namespace wird von der IETF kontrolliert.

Beachten Sie, dass die Definition neuer URI-Schemas für XML-Namespaces jetzt nicht mehr empfohlen wird. "DAV:" wurde definiert, bevor standardmäßige Best Practices entstanden.

21.2. XML Namespaces (XML-Namespaces)​

XML-Namespaces machen WebDAV-Eigenschaftsnamen und XML-Elemente eindeutig. Jeder WebDAV-Benutzer oder jede Anwendung kann einen neuen Namespace definieren, um benutzerdefinierte Eigenschaften zu erstellen oder die WebDAV-XML-Syntax zu erweitern. IANA muss solche Namespaces, Eigenschaftsnamen oder Elementnamen nicht verwalten.

21.3. Message Header Fields (Nachrichten-Header-Felder)​

Die folgenden Nachrichten-Header-Felder sollten dem permanenten Register hinzugefügt werden (siehe [RFC3864]).

21.3.1. DAV​

Header field name (Header-Feldname): DAV

Applicable protocol (Anwendbares Protokoll): http

Status (Status): standard

Author/Change controller (Autor/Änderungsverantwortlicher): IETF

Specification document (Spezifikationsdokument): this specification (Section 10.1)

21.3.2. Depth​

Header field name (Header-Feldname): Depth

Applicable protocol (Anwendbares Protokoll): http

Status (Status): standard

Author/Change controller (Autor/Änderungsverantwortlicher): IETF

Specification document (Spezifikationsdokument): this specification (Section 10.2)

21.3.3. Destination​

Header field name (Header-Feldname): Destination

Applicable protocol (Anwendbares Protokoll): http

Status (Status): standard

Author/Change controller (Autor/Änderungsverantwortlicher): IETF

Specification document (Spezifikationsdokument): this specification (Section 10.3)

21.3.4. If​

Header field name (Header-Feldname): If

Applicable protocol (Anwendbares Protokoll): http

Status (Status): standard

Author/Change controller (Autor/Änderungsverantwortlicher): IETF

Specification document (Spezifikationsdokument): this specification (Section 10.4)

21.3.5. Lock-Token​

Header field name (Header-Feldname): Lock-Token

Applicable protocol (Anwendbares Protokoll): http

Status (Status): standard

Author/Change controller (Autor/Änderungsverantwortlicher): IETF

Specification document (Spezifikationsdokument): this specification (Section 10.5)

21.3.6. Overwrite​

Header field name (Header-Feldname): Overwrite

Applicable protocol (Anwendbares Protokoll): http

Status (Status): standard

Author/Change controller (Autor/Änderungsverantwortlicher): IETF

Specification document (Spezifikationsdokument): this specification (Section 10.6)

21.3.7. Timeout​

Header field name (Header-Feldname): Timeout

Applicable protocol (Anwendbares Protokoll): http

Status (Status): standard

Author/Change controller (Autor/Änderungsverantwortlicher): IETF

Specification document (Spezifikationsdokument): this specification (Section 10.7)

21.4. HTTP Status Codes (HTTP-Statuscodes)​

Diese Spezifikation definiert die HTTP-Statuscodes

  • 207 Multi-Status (Section 11.1)
  • 422 Unprocessable Entity (Section 11.2),
  • 423 Locked (Section 11.3),
  • 424 Failed Dependency (Section 11.4) und
  • 507 Insufficient Storage (Section 11.5),

die im Register unter http://www.iana.org/assignments/http-status-codes aktualisiert werden sollen.

Hinweis: Der HTTP-Statuscode 102 (Processing) wurde in dieser Spezifikation entfernt; seine IANA-Registrierung sollte weiterhin auf RFC 2518 verweisen.

22. Acknowledgements (Danksagungen)​

Eine Spezifikation wie diese gedeiht durch durchdringende kritische Überprüfung und verkümmert durch apathische Vernachlässigung. Die Autoren erkennen dankbar die Beiträge der folgenden Personen an, deren Erkenntnisse in jeder Phase unserer Arbeit so wertvoll waren.

Beitragende zu RFC 2518​

Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse und Lauren Wood.

Zwei aus dieser Liste verdienen besondere Erwähnung. Die Beiträge von Larry Masinter waren von unschätzbarem Wert; er half sowohl bei der Bildung der Arbeitsgruppe als auch bei der geduldigen Anleitung der Autoren auf dem Weg. In vielerlei Hinsicht hat er hohe Standards gesetzt, die wir zu erreichen versuchten. Auch die Beiträge von Judith Slein waren von unschätzbarem Wert; durch die Klärung der Anforderungen und die geduldige Überprüfung von Version zu Version verbesserte sie sowohl diese Spezifikation als auch erweiterte unseren Verstand in Bezug auf Dokumentenverwaltung.

Wir möchten auch John Turner für die Entwicklung der XML-DTD danken.

Die Autoren von RFC 2518 waren Yaron Goland, Jim Whitehead, A. Faizi, Steve Carter und D. Jensen. Obwohl ihre Namen aufgrund von IETF-Autorenanzahlbeschränkungen entfernt werden mussten, können sie sich für den Großteil des Designs von WebDAV anrechnen lassen.

Zusätzliche Danksagungen für diese Spezifikation​

Bedeutende Textbeitragende für diese Spezifikation sind im folgenden Abschnitt als Beitragende aufgeführt. Wir müssen auch dankbar Geoff Clemm, Joel Soderberg und Dan Brotsky anerkennen, die spezifischen Text auf der Liste oder in Meetings ausgearbeitet haben. Joe Hildebrand und Cullen Jennings halfen viele Probleme zu schließen. Barry Lind beschrieb eine zusätzliche Sicherheitsüberlegung und Cullen Jennings lieferte Text für diese Überlegung. Jason Crawford verfolgte den Problemstatus für dieses Dokument über einen Zeitraum von Jahren, gefolgt von Elias Sinderson.

Anhang A. Notes on Processing XML Elements (Hinweise zur Verarbeitung von XML-Elementen)​

A.1. Notes on Empty XML Elements (Hinweise zu leeren XML-Elementen)​

XML unterstützt zwei Mechanismen, um anzuzeigen, dass ein XML-Element keinen Inhalt hat. Der erste besteht darin, ein XML-Element der Form &lt;A>&lt;/A> zu deklarieren. Der zweite besteht darin, ein XML-Element der Form &lt;A/> zu deklarieren. Die beiden XML-Elemente sind semantisch identisch.

A.2. Notes on Illegal XML Processing (Hinweise zur illegalen XML-Verarbeitung)​

XML ist ein flexibles Datenformat, das es einfach macht, Daten einzureichen, die legal erscheinen, es aber tatsächlich nicht sind. Die Philosophie "Sei flexibel in dem, was du akzeptierst, und streng in dem, was du sendest" gilt immer noch, aber sie darf nicht unangemessen angewendet werden. XML ist äußerst flexibel im Umgang mit Fragen von Leerzeichen, Elementreihenfolge, Einfügen neuer Elemente usw. Diese Flexibilität erfordert keine Erweiterung, insbesondere nicht im Bereich der Bedeutung von Elementen.

Es gibt keine Freundlichkeit darin, illegale Kombinationen von XML-Elementen zu akzeptieren. Im besten Fall wird es ein unerwünschtes Ergebnis verursachen und im schlimmsten Fall kann es echten Schaden anrichten.

A.3. Example - XML Syntax Error (Beispiel - XML-Syntaxfehler)​

Der folgende Anforderungskörper für eine PROPFIND-Methode ist illegal.

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:">
 &lt;D:allprop/>
 &lt;D:propname/>
&lt;D:propfind>

Die Definition des propfind-Elements erlaubt nur das allprop- oder das propname-Element, nicht beide. Daher ist das oben Genannte ein Fehler und muss mit einem 400 (Bad Request) beantwortet werden.

Stellen Sie sich jedoch vor, dass ein Server "freundlich" sein wollte und beschloss, das allprop-Element als wahres Element auszuwählen und darauf zu reagieren. Ein Client, der über eine bandbreitenbegrenzte Leitung läuft und beabsichtigte, einen propname auszuführen, würde eine große Überraschung erleben, wenn der Server den Befehl als allprop behandelte.

Wenn ein Server außerdem nachsichtig wäre und beschließen würde, auf diese Anfrage zu antworten, würden die Ergebnisse von Server zu Server zufällig variieren, wobei einige Server die allprop-Direktive ausführen und andere die propname-Direktive ausführen. Dies verringert die Interoperabilität, anstatt sie zu erhöhen.

A.4. Example - Unexpected XML Element (Beispiel - Unerwartetes XML-Element)​

Das vorherige Beispiel war illegal, weil es zwei Elemente enthielt, die explizit verboten waren, zusammen im propfind-Element zu erscheinen. XML ist jedoch eine erweiterbare Sprache, sodass man sich vorstellen kann, dass neue Elemente für die Verwendung mit propfind definiert werden. Unten ist der Anforderungskörper eines PROPFIND und muss, wie das vorherige Beispiel, von einem Server, der das expired-props-Element nicht versteht, mit einem 400 (Bad Request) abgelehnt werden.

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:"
xmlns:E="http://www.example.com/standards/props/">
 &lt;E:expired-props/>
&lt;D:propfind>

Um zu verstehen, warum ein 400 (Bad Request) zurückgegeben wird, schauen wir uns den Anforderungskörper an, wie der Server, der mit expired-props nicht vertraut ist, ihn sieht.

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:"
            xmlns:E="http://www.example.com/standards/props/">
&lt;D:propfind>

Da der Server das 'expired-props'-Element nicht versteht, muss er gemäß den in Abschnitt 17 spezifizierten WebDAV-spezifischen XML-Verarbeitungsregeln die Anfrage so verarbeiten, als ob das Element nicht vorhanden wäre. Daher sieht der Server ein leeres propfind, was nach der Definition des propfind-Elements illegal ist.

Bitte beachten Sie, dass die Erweiterung, wenn sie additiv gewesen wäre, nicht unbedingt zu einem 400 (Bad Request) geführt hätte. Stellen Sie sich beispielsweise den folgenden Anforderungskörper für ein PROPFIND vor:

&lt;?xml version="1.0" encoding="utf-8" ?>
&lt;D:propfind xmlns:D="DAV:"
            xmlns:E="http://www.example.com/standards/props/">
 &lt;D:propname/>
 &lt;E:leave-out>*boss*&lt;E:leave-out>
&lt;D:propfind>

Das vorherige Beispiel enthält das fiktive Element leave-out. Sein Zweck ist es, die Rückgabe jeder Eigenschaft zu verhindern, deren Name mit dem übermittelten Muster übereinstimmt. Wenn das vorherige Beispiel an einen Server übermittelt würde, der mit 'leave-out' nicht vertraut ist, wäre das einzige Ergebnis, dass das 'leave-out'-Element ignoriert und ein propname ausgeführt würde.

Anhang B. Notes on HTTP Client Compatibility (Hinweise zur HTTP-Client-Kompatibilität)​

WebDAV wurde so konzipiert, dass es abwärtskompatibel mit HTTP 1.1 ist, und es hat sich als abwärtskompatibel erwiesen. Die Methoden PUT und DELETE sind in HTTP definiert und können daher sowohl von HTTP-Clients als auch von WebDAV-bewussten Clients verwendet werden, aber die Antworten auf PUT und DELETE wurden in dieser Spezifikation auf eine Weise erweitert, auf die nur ein WebDAV-Client vollständig vorbereitet wäre. Einige theoretische Bedenken wurden darüber geäußert, ob diese Antworten Interoperabilitätsprobleme mit HTTP-only-Clients verursachen würden, und dieser Abschnitt behandelt diese Bedenken.

Da jeder HTTP-Client unerkannte 400-Level- und 500-Level-Statuscodes als Fehler behandeln sollte, sollten die folgenden neuen Statuscodes keine Probleme darstellen: 422, 423 und 507 (424 ist ebenfalls ein neuer Statuscode, erscheint aber nur im Körper einer Multistatus-Antwort.) Wenn also beispielsweise ein HTTP-Client versuchen würde, eine gesperrte Ressource mit PUT oder DELETE zu bearbeiten, sollte die Antwort 423 Locked zu einem allgemeinen Fehler führen, der dem Benutzer präsentiert wird.

Die Antwort 207 Multistatus ist interessant, weil ein HTTP-Client, der eine DELETE-Anfrage an eine Sammlung stellt, eine 207-Antwort als Erfolg interpretieren könnte, obwohl er nicht erkennt, dass die Ressource eine Sammlung ist, und nicht verstehen kann, dass die DELETE-Operation ein vollständiger oder teilweiser Fehler gewesen sein könnte. Diese Interpretation ist nicht vollständig gerechtfertigt, da eine 200-Level-Antwort anzeigt, dass der Server die Anfrage "empfangen, verstanden und akzeptiert" hat, nicht dass die Anfrage zu vollständigem Erfolg geführt hat.

Eine Option ist, dass ein Server einen DELETE einer Sammlung als atomare Operation behandeln könnte und entweder 204 No Content im Erfolgsfall oder eine geeignete Fehlerantwort (400 oder 500 Level) für einen Fehler verwenden könnte. Dieser Ansatz würde tatsächlich die Abwärtskompatibilität maximieren. Da jedoch Interoperabilitätstests und Arbeitsgruppendiskussionen keine Instanzen von HTTP-Clients gefunden haben, die eine DELETE-Anfrage gegen eine WebDAV-Sammlung stellen, ist diese Sorge eher theoretisch als praktisch. Daher werden Server wahrscheinlich vollständig erfolgreich mit HTTP-Clients interoperieren, selbst wenn sie jede Sammlungs-DELETE-Anfrage als WebDAV-Anfrage behandeln und eine 207 Multi-Status-Antwort senden.

Im Allgemeinen werden Server-Implementierungen ermutigt, die detaillierten Antworten und andere in diesem Dokument definierte Mechanismen zu verwenden, anstatt Änderungen aufgrund theoretischer Interoperabilitätsbedenken vorzunehmen.

Anhang C. The 'opaquelocktoken' Scheme and URIs (Das 'opaquelocktoken'-Schema und URIs)​

Das 'opaquelocktoken' URI-Schema wurde in [RFC2518] definiert (und von der IANA registriert), um syntaktisch korrekte und einfach zu generierende URIs aus UUIDs zu erstellen, die als Sperr-Tokens verwendet werden sollen und über alle Ressourcen für alle Zeit hinweg eindeutig sein sollen.

Ein opaquelocktoken-URI wird konstruiert, indem das 'opaquelocktoken'-Schema mit einer UUID verkettet wird, zusammen mit einer optionalen Erweiterung. Server können neue UUIDs für jeden neuen Sperr-Token erstellen. Wenn ein Server UUIDs wiederverwenden möchte, MUSS der Server eine Erweiterung hinzufügen, und der Algorithmus, der die Erweiterung generiert, MUSS garantieren, dass dieselbe Erweiterung niemals zweimal mit der zugehörigen UUID verwendet wird.

OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
  ; UUID ist in Abschnitt 3 von [RFC4122] definiert. Beachten Sie, dass LWS
  ; zwischen den Elementen dieser
  ; Produktion nicht erlaubt ist.

Extension = path
  ; path ist in Abschnitt 3.3 von [RFC3986] definiert

Anhang D. Lock-null Resources (Lock-null-Ressourcen)​

Das ursprüngliche WebDAV-Modell zum Sperren nicht zugeordneter URLs erstellte "Lock-null-Ressourcen". Dieses Modell war zu kompliziert und es wurden einige Interoperabilitäts- und Implementierungsprobleme entdeckt. Das neue WebDAV-Modell zum Sperren nicht zugeordneter URLs (siehe Abschnitt 7.3) erstellt "gesperrte leere Ressourcen". Lock-null-Ressourcen sind veraltet. Dieser Abschnitt behandelt das ursprüngliche Modell kurz, da Clients in der Lage sein MÜSSEN, beide Modelle zu handhaben.

Im ursprünglichen "Lock-null-Ressourcen"-Modell, das nicht mehr zur Implementierung empfohlen wird:

  • Eine Lock-null-Ressource erschien manchmal als "Not Found". Der Server antwortet mit 404 oder 405 auf jede Methode außer PUT, MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.

  • Eine Lock-null-Ressource erscheint jedoch als Mitglied ihrer übergeordneten Sammlung.

  • Der Server entfernt die Lock-null-Ressource vollständig (ihre URI wird nicht zugeordnet), wenn ihre Sperre verschwindet, bevor sie in eine reguläre Ressource umgewandelt wird. Denken Sie daran, dass Sperren nicht nur verschwinden, wenn sie ablaufen oder entsperrt werden, sondern auch entfernt werden, wenn eine Ressource umbenannt oder verschoben wird oder wenn eine übergeordnete Sammlung umbenannt oder verschoben wird.

  • Der Server wandelt die Lock-null-Ressource in eine reguläre Ressource um, wenn eine PUT-Anfrage an die URL erfolgreich ist.

  • Der Server wandelt die Lock-null-Ressource in eine Sammlung um, wenn eine MKCOL-Anfrage an die URL erfolgreich ist (obwohl Interoperabilitätserfahrungen zeigten, dass nicht alle Server dieser Anforderung folgten).

  • Eigenschaftswerte wurden für DAV:lockdiscovery- und DAV:supportedlock-Eigenschaften definiert, aber nicht unbedingt für andere Eigenschaften wie DAV:getcontenttype.

Clients können sowohl mit Servern, die das alte Modell "Lock-null-Ressourcen" unterstützen, als auch mit dem empfohlenen Modell "gesperrte leere Ressourcen" problemlos interoperieren, indem sie nach einem LOCK auf eine nicht zugeordnete URL nur PUT versuchen, nicht MKCOL oder GET.

D.1. Guidance for Clients Using LOCK to Create Resources (Anleitung für Clients, die LOCK zum Erstellen von Ressourcen verwenden)​

Ein gemäß dieser Spezifikation implementierter WebDAV-Client kann Server finden, die Lock-null-Ressourcen erstellen (vor dieser Spezifikation unter Verwendung von [RFC2518] implementiert), sowie Server, die gesperrte leere Ressourcen erstellen. Die Antwort auf die LOCK-Anfrage zeigt nicht an, welche Art von Ressource erstellt wurde. Es gibt einige Techniken, die dem Client helfen, mit beiden Typen umzugehen.

  • Wenn der Client versehentlich das Erstellen von Lock-null- oder leeren gesperrten Ressourcen vermeiden möchte, kann ein "If-Match: *"-Header mit LOCK-Anfragen eingefügt werden, um zu verhindern, dass der Server eine neue Ressource erstellt.

  • Wenn eine LOCK-Anfrage eine Ressource erstellt und der Client diese Ressource anschließend mit einer COPY- oder MOVE-Anfrage überschreiben möchte, sollte der Client einen "Overwrite: T"-Header einfügen.

  • Wenn eine LOCK-Anfrage eine Ressource erstellt und der Client sich dann entscheidet, diese Ressource loszuwerden, soll eine DELETE-Anfrage bei einer Lock-null-Ressource fehlschlagen und stattdessen UNLOCK verwendet werden. Aber bei einer gesperrten leeren Ressource lässt UNLOCK die Ressource nicht verschwinden. Daher muss der Client möglicherweise beide Anfragen versuchen und einen Fehler in einer der beiden Anfragen ignorieren.

Anhang F. Summary of Changes from RFC 2518 (Zusammenfassung der Änderungen von RFC 2518)​

Dieser Anhang bietet eine Zusammenfassung der Änderungen von RFC 2518.

F.1. Changes for Both Client and Server Implementations (Änderungen für Client- und Server-Implementierungen)​

Klarstellungen:

  • Klarstellung hinzugefügt, welche HTTP-Funktionen unterstützt werden müssen.
  • Klarstellung hinzugefügt, wann ETags zurückgegeben werden müssen.
  • Klargestellt, dass die Root-Sammlung niemals gelöscht werden kann.
  • Klargestellt, dass Clients in der Lage sein müssen, mit PROPFIND-Antworten umzugehen, die Eigenschaften in beliebiger Reihenfolge enthalten.
  • Anforderungen für PROPFIND Depth infinity-Anfragen klargestellt.
  • Klarstellung zur Verwendung des Timeout-Request-Headers hinzugefügt.
  • Klarstellung zur Behandlung von Zeitwerten hinzugefügt.

Verarbeitungsklarstellungen:

  • Klargestellt, wann die If-Header von HTTP anstelle des If-Headers von WebDAV verwendet werden können.
  • Klargestellt, dass WebDAV-Clients in der Lage sein müssen, 401-Antworten bei der Interaktion mit einem WebDAV-Server zu verarbeiten.

Erweiterte Anleitungen:

  • Anleitung zur Verwendung des DAV-Headers hinzugefügt.
  • Anleitung zur Behandlung bedingter HTTP-Header hinzugefügt.
  • Anleitung für PROPFIND-Anfragen an Sammlungen mit übermäßig vielen Ressourcen hinzugefügt.
  • Beispiel für PROPFIND-Antwort hinzugefügt und Formatanforderungen klargestellt.
  • Beispiel für COPY-Anfrage hinzugefügt und Overwrite-Header-Behandlung klargestellt.

Neue Funktionalität:

  • Statuscode 102 (Processing) wurde aus dieser Spezifikation entfernt. Er wurde nicht weit verbreitet implementiert und wurde zu RFC 2518 verschoben.

F.2. Changes for Client Implementations (Änderungen für Client-Implementierungen)​

Neue Anleitungen:

  • Anhang zur XML-Erweiterbarkeit hinzugefügt.
  • Anhang zur Authentifizierung von Clients hinzugefügt.
  • Sicherheitsüberlegungen zu den Auswirkungen von XML-Entitäten hinzugefügt.

Verarbeitungsänderungen:

  • Clients müssen nicht mehr fehlschlagen, wenn sie ungültige Reihenfolgen von Elementen in einer Antwort erhalten.

F.3. Changes for Server Implementations (Änderungen für Server-Implementierungen)​

Lock-null-Ressourcen:

  • Die vom Server unterstützten Lock-null-Ressourcen wurden zugunsten gesperrter leerer Ressourcen als veraltet erklärt.
  • Server können Lock-null-Ressourcen für Rückwärtskompatibilität weiterhin unterstützen.

Eigenschaftsänderungen:

  • Eine Reihe von Eigenschaftsdefinitionen geändert, um sie konsistenter und klarer zu machen.
  • DAV:getetag-Eigenschaft dort obligatorisch gemacht, wo DAV:getlastmodified erforderlich ist.
  • DAV:getcontenttype-Anforderung für Sammlungen entfernt.

Fehlerberichterstattung:

  • Vorbedingung/Nachbedingung-XML-Elemente für bessere Fehlerberichterstattung im Antwortkörper hinzugefügt.
  • Anleitung zur Verwendung von Vorbedingungen und Nachbedingungen hinzugefügt.

COPY/MOVE-Verhalten:

  • COPY/MOVE-Verhalten in Bezug auf Eigenschaften klargestellt.
  • COPY/MOVE-Verhalten mit Sperren klargestellt.
  • COPY/MOVE-Verhalten in Bezug auf Depth-Header klargestellt.

Sperrbehandlung:

  • Klargestellt, dass das Sperrbesitzerfeld in einer LOCK-Anfrage nicht authentifiziert ist.
  • Klargestellt, wann Sperren ablaufen müssen und wann sie verlängert werden können.
  • LockInfo-Element-Klarstellung hinzugefügt.
  • DAV:supportedlock-Schema korrigiert.

Andere Server-Änderungen:

  • Klargestellt, wann Server 404- vs. 405-Antworten verwenden müssen.
  • DELETE-Sammlungsverhalten und Fehlerberichterstattung klargestellt.
  • PROPPATCH-Transaktionsanforderungen klargestellt.
  • Die OPTIONS-Methode muss "DAV"-Header in Antworten enthalten.

F.4. Clarifications to XML Processing (Klarstellungen zur XML-Verarbeitung)​

Validierung:

  • Anforderungsstufen für XML-Verarbeitung und -Validierung klargestellt.
  • Klargestellt, dass XML-Verarbeitungsregeln nur für WebDAV-definierte Elemente gelten.
  • Anleitung zur Behandlung unbekannter XML-Elemente hinzugefügt.

Namespace-Behandlung:

  • Namespace-Verwendung in Eigenschaften und XML-Elementen klargestellt.
  • Klargestellt, dass Eigenschaftsnamen immer qualifiziert sind.

DTD-Änderungen:

  • Die DTD wurde aus der Spezifikation entfernt. Sie war nie normativ und war manchmal inkorrekt oder unvollständig.

F.5. Clarifications to Protocol Details (Klarstellungen zu Protokolldetails)​

Statuscode-Klarstellungen:

  • Klargestellt, wann jeder WebDAV-Statuscode verwendet werden muss oder sollte.
  • Interaktion von WebDAV-Statuscodes mit HTTP-Statuscodes klargestellt.

Header-Klarstellungen:

  • Depth-Header-Verwendung mit verschiedenen Methoden klargestellt.
  • If-Header-Syntax und -Verarbeitung klargestellt.
  • Overwrite-Header-Verwendung klargestellt.

Antwortformat:

  • Anforderungen für Multi-Status-Antwortformatierung klarer gemacht.
  • href-Behandlung in allen Verwendungen konsistent gemacht.

Fehlerbehandlung:

  • Fehlerbehandlung durchgehend mit Vorbedingung/Nachbedingung-Elementen verbessert.
  • Spezifische Anleitung für die Behandlung von Autorisierungsfehlern hinzugefügt.