Zum Hauptinhalt springen

11-25. Kapitel 11-25 Zusammenfassung (Chapters 11-25 Summary)

RFC 4918 Kapitel 11-25 Technische Zusammenfassung​

Dieses Dokument fasst die wichtigsten technischen Inhalte der Kapitel 11–25 von RFC 4918 zusammen, einschließlich Statuscod-Erweiterungen, XML-Definitionen, Konformitätsanforderungen und weiterer Themen.

11. Status Code Extensions (HTTP/1.1-Statuscode-Erweiterungen)​

WebDAV führt fünf neue HTTP-Statuscodes ein:

11.1 207 Multi-Status​

Zweck: Zusammengesetzte Antwort (Compound Response) für Batch-Operationen
Anwendungsfälle: PROPFIND, PROPPATCH, COPY, MOVE, DELETE

Beispiel:

HTTP/1.1 207 Multi-Status
Content-Type: application/xml

<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/resource1</D:href>
    <D:status>HTTP/1.1 200 OK</D:status>
  </D:response>
  <D:response>
    <D:href>/resource2</D:href>
    <D:status>HTTP/1.1 403 Forbidden</D:status>
  </D:response>
</D:multistatus>

Dieser Statuscode MUSS verwendet werden, wenn eine Methode auf mehrere Ressourcen angewendet wird und für jede Ressource ein eigener Statuscode zurückgegeben werden soll.

11.2 422 Unprocessable Entity (Nicht verarbeitbare Entität)​

Bedeutung: Die Anfrage ist syntaktisch korrekt, enthält aber semantische Fehler.
Anwendungsfall: Das XML-Dokument ist wohlgeformt, verstößt aber gegen Geschäftsregeln.

11.3 423 Locked (Gesperrt)​

Bedeutung: Die Zielressource ist gesperrt (Locked).
Anwendungsfall: Ein Client versucht, eine gesperrte Ressource zu ändern, ohne das entsprechende Sperr-Token (Lock Token) zu übermitteln.

11.4 424 Failed Dependency (Fehlgeschlagene Abhängigkeit)​

Bedeutung: Die aktuelle Operation konnte nicht ausgeführt werden, weil eine vorherige Operation fehlgeschlagen ist.
Anwendungsfall: Abhängigkeitsfehler (Dependency Failure) innerhalb einer Batch-Operation.

11.5 507 Insufficient Storage (Unzureichender Speicher)​

Bedeutung: Der Server verfügt nicht über ausreichend Speicherplatz, um die Anfrage zu erfüllen.
Anwendungsfall: Eine Ressource kann nicht gespeichert oder eine Operation nicht abgeschlossen werden.

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

12.1 412 Precondition Failed (Vorbedingung nicht erfüllt)​

In WebDAV wird dieser Code verwendet, wenn:

  • Die Bedingungen des If-Headers nicht erfüllt sind
  • Overwrite: F gesetzt ist, aber die Zielressource bereits existiert
  • Die Validierung des Sperr-Tokens fehlschlägt

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

Dieser Code wird zurückgegeben, wenn die URI die vom Server unterstützte maximale Länge überschreitet.

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

Grundkonzept​

Eine Mehrstatus-Antwort (Multi-Status Response) ermöglicht es dem Server, Statusinformationen für mehrere Ressourcen in einer einzigen HTTP-Antwort zurückzugeben.

Struktur:

<multistatus>
  <response>*
  <responsedescription>?
</multistatus>

13.1 Antwort-Header​

  • Content-Type: application/xml MUSS gesetzt sein
  • Ein Location-Header KANN für neu erstellte Ressourcen enthalten sein

13.2 Behandlung umgeleiteter Unterressourcen​

Der Server SOLLTE Weiterleitungen (Redirects) folgen und den Status der endgültigen Ressource melden. Wenn eine Unterressource umgeleitet wird, KANN der Server entweder den Umleitungsstatus oder den Status der Zielressource zurückgeben.

13.3 Interne Statuscodes​

Die Statuscodes innerhalb einer Mehrstatus-Antwort KÖNNEN beliebige gültige HTTP-Statuscodes sein. Clients MÜSSEN alle gültigen HTTP-Statuscodes verarbeiten können, auch wenn sie nicht explizit in RFC 4918 aufgeführt sind.

14. XML Element Definitions (XML-Elementdefinitionen)​

WebDAV definiert ein vollständiges XML-Vokabular (XML Vocabulary). Alle WebDAV-XML-Elemente gehören zum Namensraum (Namespace) DAV:.

Hauptkategorien der Elemente​

1. Anfrage-Elemente (Request Elements):

  • propfind – Anfrage zur Eigenschaftsabfrage (Property Find Request)
  • propertyupdate – Anfrage zur Eigenschaftsaktualisierung
  • lockinfo – Sperrinformationen
  • prop – Eigenschaftsliste

2. Antwort-Elemente (Response Elements):

  • multistatus – Mehrstatus-Antwort
  • response – Antwort für eine einzelne Ressource
  • propstat – Eigenschaftsstatus (Property Status)

3. Eigenschafts-Elemente (Property Elements):

  • Siehe Kapitel 15 für eine detaillierte Beschreibung

4. Fehler-Elemente (Error Elements):

  • Siehe Kapitel 16 für eine detaillierte Beschreibung

Unbekannte XML-Elemente MÜSSEN von Clients und Servern ignoriert werden, um die Erweiterbarkeit (Extensibility) zu gewährleisten.

15. DAV Properties (DAV-Eigenschaften)​

WebDAV definiert einen Standardsatz von Eigenschaften (Properties), die in lebende Eigenschaften (Live Properties) und tote Eigenschaften (Dead Properties) unterteilt werden.

Kernlebende Eigenschaften (Core Live Properties)​

EigenschaftsnameTypBeschreibung
creationdateLebendErstellungsdatum der Ressource
displaynameLebend/TotAnzeigename der Ressource
getcontentlanguageLebendInhaltssprache (Content Language)
getcontentlengthLebendInhaltslänge in Bytes
getcontenttypeLebendMIME-Typ des Inhalts
getetagLebendEntity-Tag (ETag)
getlastmodifiedLebendZeitpunkt der letzten Änderung
lockdiscoveryLebendInformationen zu aktiven Sperren
resourcetypeLebendRessourcentyp (z. B. Sammlung)
supportedlockLebendUnterstützte Sperrtypen

Eigenschaften der Eigenschaftstypen​

  • Lebende Eigenschaften (Live Properties): Werden vom Server berechnet und verwaltet; ihr Wert spiegelt den tatsächlichen Zustand der Ressource wider.
  • Tote Eigenschaften (Dead Properties): Werden vom Client gesetzt und vom Server unverändert gespeichert.
  • Geschützte Eigenschaften (Protected Properties): Können nicht über PROPPATCH geändert werden; Änderungsversuche MÜSSEN mit 403 Forbidden abgelehnt werden.

16. Precondition/Postcondition XML Elements (Vor- und Nachbedingungs-XML-Elemente)​

Zweck​

Diese Elemente liefern maschinenlesbare Fehlerinformationen (Machine-Readable Error Information) und ermöglichen es Clients, den genauen Fehlergrund zu ermitteln.

Häufige Vorbedingungselemente (Precondition Elements)​

  • lock-token-matches-request-uri – Das Sperr-Token stimmt mit der Anfrage-URI überein
  • lock-token-submitted – Ein Sperr-Token MUSS übermittelt werden
  • no-conflicting-lock – Es darf keine konfliktbehaftete Sperre vorhanden sein
  • no-external-entities – Externe XML-Entitäten (External Entities) sind nicht erlaubt
  • preserved-live-properties – Lebende Eigenschaften MÜSSEN erhalten bleiben
  • propfind-finite-depth – PROPFIND mit Depth: infinity ist auf dieser Ressource nicht erlaubt

Fehlerantworten SOLLTEN das entsprechende Vor- oder Nachbedingungselement im Antwort-Body enthalten, um dem Client eine präzise Fehlerdiagnose zu ermöglichen.

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

Erweiterungsprinzipien​

  1. Neue Elemente hinzufügen: Neue XML-Elemente KÖNNEN an beliebigen Stellen hinzugefügt werden, sofern sie einem eigenen Namensraum angehören.
  2. Neue Eigenschaften definieren: Neue DAV-Eigenschaften KÖNNEN mit eigenem Namensraum definiert werden.
  3. Unbekannte Elemente ignorieren: Clients und Server MÜSSEN unbekannte XML-Elemente ignorieren, ohne einen Fehler zu erzeugen.
  4. Namensräume verwenden: XML-Namensräume (XML Namespaces) MÜSSEN verwendet werden, um Namenskonflikte zu vermeiden.

Empfohlene Vorgehensweise​

  • Erweiterungen SOLLTEN in einem eigenen Namensraum definiert werden
  • Abwärtskompatibilität (Backward Compatibility) SOLLTE gewahrt bleiben
  • Erweiterungsverhalten SOLLTE dokumentiert werden

18. DAV Compliance Classes (DAV-Konformitätsklassen)​

Klasse 1 (Class 1 – Grundlegendes WebDAV)​

Pflichtunterstützung:

  • Methoden PROPFIND und PROPPATCH
  • Methode MKCOL
  • Erweiterte GET/HEAD-Unterstützung für Sammlungen (Collections)
  • Erweiterte PUT- und DELETE-Unterstützung
  • Methoden COPY und MOVE
  • DAV-Header gibt "1" zurück
  • Alle in Kapitel 15 definierten Eigenschaften
  • Entity-Tags (ETags)

Klasse 2 (Class 2 – Mit Sperr-Unterstützung)​

Umfasst Klasse 1, zusätzlich:

  • Methoden LOCK und UNLOCK
  • Unterstützung des Timeout-Headers
  • Unterstützung des If-Headers
  • Lock-Token-Header
  • DAV-Header gibt "1, 2" zurück

Klasse 3 (Class 3 – Geordnete Sammlungen)​

Umfasst Klasse 1, zusätzlich:

  • Unterstützung für geordnete Sammlungen (Ordered Collections)
  • DAV-Header gibt "1, 3" oder "1, 2, 3" zurück

Ein Server MUSS mindestens Klasse 1 implementieren, um als WebDAV-konform zu gelten. Die Unterstützung von Klasse 2 und Klasse 3 ist optional.

19. Internationalization Considerations (Internationalisierungsüberlegungen)​

Wesentliche Punkte​

  1. UTF-8-Kodierung: XML-Dokumente MÜSSEN in UTF-8 kodiert sein, sofern keine andere Kodierung explizit angegeben wird.
  2. xml:lang-Attribut: Eigenschaftswerte KÖNNEN mit dem xml:lang-Attribut mit einer Sprachkennung versehen werden.
  3. Eigenschaftswerte: KÖNNEN beliebige Unicode-Zeichen enthalten.
  4. URL-Kodierung: Internationalisierte URLs (Internationalized Resource Identifiers, IRIs) MÜSSEN gemäß RFC 3986 korrekt prozentcodiert werden.

20. Security Considerations (Sicherheitsüberlegungen)​

Wesentliche Sicherheitsaspekte​

1. Authentifizierung und Autorisierung (Authentication and Authorization):

  • Es MÜSSEN geeignete Authentifizierungsmechanismen eingesetzt werden
  • Feingranulare Zugriffskontrollen (Fine-Grained Access Controls) SOLLTEN implementiert werden
  • Sensible Eigenschaften MÜSSEN geschützt werden

2. Denial-of-Service (DoS):

  • Anfragen mit Depth: infinity SOLLTEN begrenzt oder abgelehnt werden
  • Ressourcenkontingente (Resource Quotas) SOLLTEN implementiert werden
  • Timeout-Mechanismen MÜSSEN vorhanden sein

3. Informationsoffenlegung (Information Disclosure):

  • Fehlermeldungen MÜSSEN sorgfältig formuliert werden, um keine sensiblen Informationen preiszugeben
  • Sperr-Tokens MÜSSEN geschützt werden
  • Angemessene Autorisierungsprüfungen MÜSSEN durchgeführt werden

4. XML-Sicherheit (XML Security):

  • XML-Entity-Expansion-Angriffe (XML Entity Expansion Attacks) MÜSSEN verhindert werden
  • Die Größe von XML-Dokumenten SOLLTE begrenzt werden
  • Externe XML-Entitäten MÜSSEN deaktiviert werden

21. IANA Considerations (IANA-Überlegungen)​

Registrierte Inhalte​

  1. URI-Schema-Registrierung: "opaquelocktoken" als neues URI-Schema
  2. HTTP-Header-Registrierung: DAV, Depth, Destination, If, Lock-Token, Overwrite, Timeout
  3. HTTP-Statuscodes: 207, 422, 423, 424, 507
  4. XML-Namensraum: "DAV:"

22–24. Acknowledgements / Contributors / Authors (Danksagungen / Mitwirkende / Autoren)​

RFC 4918 ist das Ergebnis der gemeinsamen Arbeit zahlreicher Mitglieder der WebDAV-Community. Besonderer Dank gilt:

  • Den ursprünglichen Autoren von RFC 2518
  • Den Mitgliedern der WebDAV-Arbeitsgruppe (WebDAV Working Group)
  • Implementierern und frühen Anwendern für ihr wertvolles Feedback

25. References (Referenzen)​

25.1 Normative Referenzen (Normative References)​

  • RFC 2119: Schlüsselwörter für die Verwendung in RFCs zur Angabe von Anforderungsstufen
  • RFC 2616: Hypertext Transfer Protocol – HTTP/1.1
  • RFC 3986: Uniform Resource Identifier (URI): Generische Syntax
  • REC-XML: Extensible Markup Language (XML) 1.0
  • REC-XML-NAMES: Namensräume in XML

25.2 Informative Referenzen (Informative References)​

  • RFC 2518: HTTP Extensions for Distributed Authoring – WebDAV (durch RFC 4918 ersetzt)
  • RFC 3253: Versioning Extensions to WebDAV (WebDAV-Versionsverwaltung)
  • RFC 3744: Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol
  • Weitere verwandte RFCs

Zusammenfassung: Die Kapitel 11–25 behandeln die Implementierungsdetails, Konformitätsanforderungen, Sicherheitsüberlegungen und Internationalisierungsunterstützung von WebDAV. Diese Kapitel sind für die Implementierung eines vollständigen WebDAV-Servers oder -Clients unerlässlich. Die wichtigsten Punkte umfassen die korrekte Verwendung von HTTP-Statuscodes, die Implementierung von XML-Erweiterbarkeit, die Erfüllung der Konformitätsanforderungen sowie die Behandlung von Sicherheitsproblemen.

Letztes Update am