Zum Hauptinhalt springen

RFC 4918 Technische Kernpunkte der Anhänge

Dieses Dokument fasst den Hauptinhalt der Anhänge A-F von RFC 4918 zusammen.

Anhang A. Processing XML Elements (Überlegungen zur Verarbeitung von XML-Elementen)​

Schlüsselpunkte​

1. XML-Parsing-Anforderungen:

  • Muss einen W3C-standardkonformen XML-Parser verwenden
  • Muss XML-Namespaces unterstützen
  • Muss wohlgeformtes XML verarbeiten

2. Verarbeitung unbekannter Elemente:

  • Clients und Server müssen nicht erkannte XML-Elemente ignorieren
  • Dies gewährleistet Vorwärtskompatibilität
  • Erweiterungen brechen keine bestehenden Implementierungen

3. Whitespace-Verarbeitung:

  • Whitespace in Attributwerten ist bedeutungsvoll
  • Whitespace in Attributwerten muss beibehalten werden
  • xml:space-Attribut ignorieren

4. Sicherheitsüberlegungen:

  • Externe Entitäten deaktivieren, um XXE-Angriffe zu verhindern
  • XML-Dokumentgröße begrenzen
  • Parsing-Tiefe begrenzen

Anhang B. HTTP Client Compatibility (Überlegungen zur HTTP-Client-Kompatibilität)​

Kompatibilitätsrichtlinien​

1. HTTP/1.1-Clients:

  • Basis-HTTP/1.1-Clients können auf WebDAV-Ressourcen zugreifen
  • Können jedoch keine WebDAV-spezifischen Funktionen verwenden (Sperren, Eigenschaften usw.)
  • Verwenden Standard-HTTP-Methoden (GET, PUT, DELETE)

2. Teilweise WebDAV-Unterstützung:

  • Clients können eine Teilmenge von WebDAV implementieren
  • Sollten Serverfähigkeiten über OPTIONS entdecken
  • Graceful Degradation zu HTTP/1.1-Funktionen

3. Interoperabilität:

  • HTTP-Spezifikationen befolgen
  • Weiterleitungen korrekt behandeln
  • Persistente Verbindungen unterstützen

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

opaquelocktoken URI-Schema​

Definition: Speziell für WebDAV-Sperr-Token entwickeltes URI-Schema

Syntax:

opaquelocktoken:<UUID>

Beispiel:

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

Eigenschaften:

  • Global eindeutig: Verwendet UUID zur Gewährleistung der Eindeutigkeit
  • Opak: Clients sollten seine interne Struktur nicht parsen
  • URL-sicher: Kann in HTTP-Headern und XML verwendet werden

Verwendungsszenarien:

  • Von der LOCK-Methode zurückgegebenes Sperr-Token
  • Im If-Header gesendetes Sperr-Token
  • Im Lock-Token-Header angegebenes Sperr-Token

Unterschied zu anderen URIs:

  • Nicht dereferenzierbar (keine entsprechende Ressource)
  • Nur zur Identifizierung von Sperren verwendet
  • Lebenszyklus identisch mit der Sperre

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

Konzept der Sperr-Null-Ressource (LNR)​

Definition: Spezieller Ressourcentyp, der in RFC 2518 definiert wurde, erstellt durch Ausführen von LOCK auf einer nicht zugeordneten URL.

Änderungen in RFC 4918:

  • RFC 4918 empfiehlt die Verwendung von "gesperrten leeren Ressourcen" anstelle von LNR
  • Aber zur Rückwärtskompatibilität können Server LNR weiterhin unterstützen

Gesperrte leere Ressourcen vs LNR​

MerkmalGesperrte leere Ressource (empfohlen)Lock-Null Resource (Kompatibilität)
ErstellungsmethodeLOCK auf nicht zugeordneter URLLOCK auf nicht zugeordneter URL
GET-VerhaltenGibt 200 und leeren Inhalt zurückGibt 404 zurück
EigenschaftenNormale RessourceneigenschaftenSpezielle LNR-Eigenschaften
SichtbarkeitAls Sammlungsmitglied sichtbarMöglicherweise nicht sichtbar
MKCOLSchlägt fehl (405)Wird in Sammlung konvertiert

Client-Kompatibilitätsempfehlungen:

  • Nach Ausführung von LOCK auf einer nicht zugeordneten URL PUT verwenden, um Inhalt hinzuzufügen
  • Nicht auf spezifisches Verhalten von GET oder MKCOL verlassen
  • Nicht auf spezifische Eigenschaften von LNR verlassen

Anhang E. Guidance for Clients Desiring to Authenticate (Leitfaden für Clients, die sich authentifizieren möchten)​

Authentifizierungserkennung​

Problem: Wie erkennt ein Client, dass eine Ressource Authentifizierung erfordert?

Methode 1 - Proaktive OPTIONS-Anfrage:

OPTIONS /resource HTTP/1.1
Host: example.com

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="WebDAV"

Methode 2 - Operation versuchen und 401 behandeln:

PROPFIND /resource HTTP/1.1
Host: example.com

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="WebDAV"

Best Practices für Authentifizierung​

1. Mehrere Authentifizierungsschemata unterstützen:

  • Basic-Authentifizierung (erfordert HTTPS)
  • Digest-Authentifizierung
  • OAuth 2.0 Bearer-Token
  • Client-Zertifikate

2. Authentifizierungsinformationen cachen:

  • Informationen für denselben Realm cachen
  • Geeignete Timeouts implementieren
  • Sensible Informationen sicher speichern

3. Authentifizierungsfehler behandeln:

  • Klare Fehlermeldungen bereitstellen
  • Erneute Authentifizierung erlauben
  • Kontosperrung vermeiden

4. Sicherheitsüberlegungen:

  • Immer HTTPS verwenden, um Anmeldeinformationen zu übertragen
  • Keine Passwörter in URL einschließen
  • Rate Limiting implementieren, um Brute-Force-Angriffe zu verhindern

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

RFC 4918 obsoliert RFC 2518, wichtige Änderungen umfassen:

F.1 Änderungen bei Client- und Serverimplementierungen​

1. Entfernung von Sperr-Null-Ressourcen (LNR):

  • Empfiehlt die Verwendung von "gesperrten leeren Ressourcen"
  • Vereinfacht die Implementierung
  • Verbessert die Interoperabilität

2. Klarstellung der If-Header-Syntax:

  • Klarere Matching-Regeln
  • Verbesserte Beispiele
  • Beseitigt Mehrdeutigkeiten

3. Sammlungsverhalten:

  • Klärt DELETE-Verhalten bei Sammlungen
  • Klärt die Verwendung des Depth-Headers
  • Verbessert Fehlerbehandlung

4. Eigenschaftsverarbeitung:

  • Klärt Live-Eigenschaften vs. tote Eigenschaften
  • Verbessert PROPPATCH-Atomaritätsanforderungen
  • Klärt XML-Verarbeitung von Eigenschaftswerten

F.2 Änderungen bei Serverimplementierungen​

1. 207 Multi-Status-Antwort:

  • Strengere Formatanforderungen
  • Verbesserte Fehlerberichterstattung
  • Erforderliches href-Element

2. Sperrverhalten:

  • Klärt Sperr-Aktualisierungsmechanismus
  • Verbessert Timeout-Behandlung
  • Klärt Anforderungen zur Sperr-Token-Übermittlung

3. COPY/MOVE-Semantik:

  • Klärt Overwrite-Header-Verhalten
  • Verbessert Zielressourcenbehandlung
  • Klärt Auswirkungen von Sperren

F.3 Weitere Änderungen​

1. Sicherheitsverbesserungen:

  • Fügt XML-Sicherheitsrichtlinien hinzu
  • Verbessert DoS-Schutzempfehlungen
  • Klärt Authentifizierungsanforderungen

2. Interoperabilitätsverbesserungen:

  • Klarere Spezifikationen
  • Mehr Beispiele
  • Beseitigt Implementierungsmehrdeutigkeiten

3. Veraltete Funktionen:

  • Einige optionale Funktionen von RFC 2518
  • Vereinfacht Konformitätsanforderungen
  • Reduziert Implementierungsaufwand

Zusammenfassung der Anhänge​

Die Anhänge bieten folgende wichtige Informationen:

  1. Implementierungsrichtlinien (A, B): XML-Verarbeitung und HTTP-Kompatibilität
  2. Technische Details (C, D): Sperr-Token-URI-Schema und Sperr-Null-Ressourcen
  3. Praktische Empfehlungen (E): Richtlinien zur Authentifizierungsimplementierung
  4. Entwicklungsgeschichte (F): Änderungen von RFC 2518 zu RFC 4918

Diese Anhänge sind sehr wertvoll für die Implementierung hochwertiger WebDAV-Clients und -Server.

Letztes Update am