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 Zustand | Gemeinsame Sperranfrage | Exklusive 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.