Zusammenfassung

  • Für jede WebDAV-Sperre erzeugt der Server ein eindeutiges Token. Seine Übermittlung im Feld If belegt die Kenntnis dieses Bezeichners, nicht die Identität des Absenders, dessen Schreibrecht oder den Fortbestand der Sperre.
  • Eine Änderung durchläuft getrennte Prüfungen: authentifizierter Principal, methodenspezifisches Privileg, vollständige Menge betroffener Ressourcen, Bedingungen und ETags, direkte und indirekte Sperren, Ersteller oder autorisierter Override sowie Zustand beim Commit.
  • Gemeinsam genutzte Sperren, Collection-Tiefe, COPY/MOVE und serverseitig gewählte Timeouts machen aus dem Token keinen transportablen Mietvertrag. Es bleibt eng begrenzte Koordinationsevidenz.

Zwei Ablehnungen, zwei Ursachen

Ein Client sendet ein PUT mit dem Token einer bestehenden Sperre. In einem Fall ist das ETag in If überholt: Der Server antwortet 412 Precondition Failed. In einem zweiten Fall betrifft die Operation eine weitere gesperrte Ressource, deren Token fehlt: Der Server antwortet 423 Locked mit der Vorbedingung lock-token-submitted. In einem dritten Fall stimmt das Token, aber dem angemeldeten Benutzer fehlt das Schreibrecht: Die Autorisierung verweigert die Operation.

Ein Dashboard kann daraus dreimal „Lock failed“ machen. Das Protokoll tut es bewusst nicht. Nach RFC 4918 muss der Server bei einer Änderung an einer gesperrten Ressource zusätzlich zur gültigen Token-Übermittlung prüfen, ob der authentifizierte Principal dem Ersteller der Sperre entspricht. Eine Sperre verleiht außerdem keine vollständigen Änderungsrechte. Normale Authentifizierung und Privilegien bleiben verbindlich.

Das Token beantwortet nur, welche Sperre der Request kennt. Es sagt nicht, wer spricht, welche Methode erlaubt ist, welche Ressourcen die Methode tatsächlich verändert und ob die Voraussetzungen im Commit-Moment noch gelten. Diese Trennung ist kein unnötiger Mehraufwand, sondern verhindert ein unentworfenes Bearer-System.

Eindeutigkeit ist Referenz, nicht Delegation

WebDAV ergänzt HTTP um Remote-Authoring, Properties, Collections, Namensraumoperationen und Kollisionsvermeidung. Die Schreibsperre soll insbesondere verlorene Aktualisierungen verhindern, bei denen ein Bearbeiter die Änderung eines anderen unbemerkt überschreibt.

Jede Sperre hat genau ein vom Server erzeugtes, eindeutiges Token. Clients dürfen seine Struktur nicht interpretieren. RFC 4918 verlangt, dass Token-URIs über alle Ressourcen und alle Zeit hinweg eindeutig sind. Eine neu erstellte Sperre wird im Response-Feld Lock-Token und im Response-Body zurückgegeben.

Diese starke Eindeutigkeit verhindert Verwechslung. Sie vergibt keine Befugnis. Aktive Sperren können über DAV:lockdiscovery sichtbar sein; Token-Geheimhaltung allein darf deshalb nicht als Zugriffskontrolle dienen.

RFC 4918 empfiehlt UUID-URNs, hält das dauerhaft registrierte Schema opaquelocktoken aufrecht und erlaubt andere eindeutige URIs. RFC 9562 empfiehlt einen kryptografisch sicheren Pseudozufallszahlengenerator, wenn Unvorhersagbarkeit wichtig ist. Zufall erschwert das Erraten, prüft aber weder DAV:write-content noch DAV:bind.

Sechs Funktionen gehören in getrennte Schichten: Eindeutigkeit unterscheidet Sperren; Unvorhersagbarkeit senkt Entdeckung; Übermittlung zeigt Wertkenntnis; Authentifizierung bindet den Request an einen Principal; Autorisierung entscheidet über die Handlung; Ausführung verändert den gegenwärtigen Zustand. Das Token darf die letzten drei nicht übernehmen.

Der Ersteller besitzt die Sperre, nicht die Ressource

Der Ersteller hat eine besondere Beziehung zu seiner Sperre, kann sie aber nur innerhalb seiner normalen Rechte einsetzen. Der Server darf einem Ressourcenverantwortlichen, Administrator oder anderen privilegierten Principal erlauben, eine fremde Sperre zu entfernen.

RFC 3744 zerlegt „Schreiben“ in sinnvollere Rechte. DAV:write-content steuert vorhandenen Inhalt, DAV:write-properties bestimmte Properties, DAV:bind die Aufnahme eines Members in eine Collection und DAV:unlock UNLOCK durch einen anderen Principal. Ein PUT auf eine noch nicht zugeordnete URI benötigt Bind-Befugnis an der Parent-Collection.

Ein Schreibberechtigter darf daher eine fremde Sperre nicht ignorieren. Umgekehrt umgeht ein Token keine ACL. Administrative Entfernung ist ein gesondert autorisierter und zurechenbarer Override, nicht nachträglich erfundene Eigentümerschaft.

Heng Lus Trennung von Aufzeichnung und Autorität beschreibt das treffend. Das Token zeichnet einen Koordinationszustand auf. Die praktische Entscheidungsgewalt liegt bei den Systemen, die Identität feststellen, Policy auswerten, den Namensraum auflösen, persistent schreiben und Recovery ausführen.

If übermittelt und bewertet

Das WebDAV-Feld If hat zwei Rollen, die ein Proxy nicht auf einen Booleschen Wert reduzieren darf.

Als Bedingung verknüpft es State Tokens und ETags. Bedingungen in einer State List gelten gemeinsam per AND. Mehrere Listen sind OR-Alternativen. Not negiert die folgende Bedingung. Untagged Lists beziehen sich auf die Request-URI; Tagged Lists nennen ihre Ressource.

Zugleich zählt das Vorkommen eines Sperrtokens in If als Übermittlung. Das bleibt auch dann wahr, wenn eine andere Alternativliste den Gesamtausdruck erfüllt. Mehrressourcenoperationen benötigen diese Unterscheidung, um Bedingungen auszudrücken und alle erforderlichen Tokens einzureichen.

Ein Gateway, das nur den „erfolgreichen Zweig“ weiterreicht, kann ein notwendiges Token löschen. Ein Log mit der Angabe „Token vorhanden“ kann ein falsches ETag verschweigen. Erfasst werden müssen übermittelte Werte, ausgewertete Listen, Zielressourcen und Resultate.

Ein falsches If führt nach der Autorisierung zu 412. Fehlt für eine betroffene gesperrte Ressource ein erforderliches Token, beschreibt 423 mit lock-token-submitted den Mangel. Der erste Fall widerlegt die Zustandsbedingung; der zweite benennt fehlende Koordinationsevidenz.

Das Feld Lock-Token ist enger: Es gibt das neue Token im LOCK-Response zurück und bezeichnet in UNLOCK die zu entfernende Sperre. PUT, PROPPATCH, COPY, MOVE und DELETE reichen State Tokens über If ein.

Die sichtbare URI ist nicht die Wirkungsmenge

Eine Sperre hat Root, Scope, Typ und Depth. Eine direkte Sperre entsteht an ihrer Root-URL. Eine Depth-infinity-Sperre auf einer Collection gilt indirekt für deren Nachkommen und für später aufgenommene Members.

Eine Datei kann folglich durch die Parent-Collection gesperrt sein, obwohl das Frontend an der Datei selbst nichts anzeigt. Der Server muss den aktuellen Namensraum und sämtliche anwendbaren Sperren auflösen.

LOCK erlaubt Depth 0 oder infinity; ohne Angabe gilt infinity. Scheitert eine Hierarchiesperre an einem inkompatiblen Member, darf kein teilweise gesperrter Baum zurückbleiben. Die Operation ist im angeforderten Bereich ganz oder gar nicht; Multi-Status kann den Blocker ausweisen.

COPY, MOVE und DELETE erweitern die Wirkungsmenge um Quelle, Ziel, Parent-Collection und gegebenenfalls überschriebenen Bestand. Alle Tokens, die für die betroffenen Ressourcen erforderlich sind, müssen vorliegen.

MOVE widerlegt besonders deutlich die Vorstellung eines transportablen Tokens. Eine direkte Sperre folgt der Ressource nicht an die neue URL. Die Ressource kann den indirekten Bereich der Quelle verlassen und in eine Depth-infinity-Sperre am Ziel eintreten. Bedeutung entsteht aus dem aktuellen Namensraum, nicht aus einem dauerhaften Recht im Inhalt.

Ein Autorisierungsdienst mit nur einem Pfad und einem Token kann eine Operation über mehrere Collection-Beziehungen nicht korrekt beurteilen. Die gesamte Menge muss vorab berechnet und beim Commit erneut geprüft werden.

Shared bedeutet mehrere eigenständige Sperren

Eine Shared-Sperre lässt kompatible Shared-Sperren zu. Jeder erfolgreiche LOCK erzeugt dennoch eine eigene Sperre mit eigenem Token. Drei Mitwirkende teilen kein Gruppenpasswort.

Refresh einer Sperre verlängert die anderen nicht. UNLOCK entfernt die bezeichnete Sperre, garantiert aber keine ungesperrte Ressource; andere Shared- oder indirekte Sperren können bleiben.

Merge, Review, Reihenfolge und Konfliktentscheidung definiert die Anwendung. WebDAV definiert technische Kompatibilität. Das Wort „shared“ erzeugt weder kollektives Eigentum noch Mehrheitsentscheidung.

Ein Betriebswerkzeug sollte Ersteller, Root, Depth, direkte oder indirekte Beziehung, Timeout und die Wirkung jedes UNLOCK darstellen. Ein einziges Locked-Bit ist für die Analyse zu grob.

Der Server bestimmt die Frist

Der Client darf in Timeout eine Dauer vorschlagen. Der Server wählt die tatsächlich gewährte Dauer und kann den Wunsch ignorieren oder ändern.

Ein Refresh ist ein körperloser LOCK mit genau einem Token in If. Der Server ignoriert Depth, startet bei Erfolg den Timer neu, lässt andere Shared-Sperren unverändert und liefert aktualisiertes DAV:lockdiscovery. Ein neues Lock-Token-Response-Feld gibt es nicht.

Ein fehlgeschlagener Refresh darf nicht als Erfolg gelten. Vor Ablauf der lokalen Uhr ist die Sperre nicht garantiert: Override, Crash oder Zustandsverlust können sie entfernen. Umgekehrt beweist ein lokal berechneter Ablauf nicht, dass der Server sie genau dann gelöscht hat.

Timeout ist Erneuerungspflicht und Aufräumhilfe, kein harter Lease. Vor einem folgenreichen Commit werden Token, Serverzustand und Ressourcenfassung erneut geprüft.

Ein rekonstruierbarer Schreibpfad

Eine belastbare Implementierung trennt:

  1. Principal authentifizieren;
  2. konkrete Operation autorisieren;
  3. Quelle, Ziel, Parents und Overwrite-Ziele auflösen;
  4. direkte, indirekte, exklusive und Shared-Sperren finden;
  5. If, Tags, ETags, Not und Alternativen vollständig parsen;
  6. alle erforderlichen Tokens bestätigen;
  7. Principal mit Ersteller oder autorisiertem Override verbinden;
  8. Zustand beim Commit neu prüfen und spezifikationsgemäß atomar ausführen;
  9. Identitäts-, Privileg-, Bedingungs-, Token-, Scope- und Commitfehler getrennt protokollieren.

Ein keyed Fingerprint kann das rohe Token im Log ersetzen. Principal, Methode, Ressourcen, Roots, Depths, Entscheidung, tatsächlicher Timeout, Endfassung und Status ergeben die Mindestspur.

Tests müssen Grenzen kreuzen: richtiges Token mit anderem Principal; Privileg ohne Token; Token mit falschem ETag; neues Member unter unendlicher Collection-Sperre; gescheiterter Hierarchie-LOCK ohne Teilzustand; MOVE ohne Mitnahme der direkten Sperre und mit Ziel-Sperre; mehrere Shared-Sperren, von denen nur eine refreshed oder entfernt wird; zurechenbarer Admin-Override; alternativer Schreibpfad ohne stillen Bypass.

WebDAV verhindert eine Klasse verlorener Aktualisierungen. Es löst keine fachlichen Deadlocks, semantischen Merges, direkten Storage-Zugriffe oder verteilten Transaktionen. Die gemeinsame Spezifikation bleibt stark, wenn ihre Autorität eng bleibt.

Quellen