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

Methode	Depth-Unterstützung	Standardwert
PROPFIND	0, 1, infinity	infinity
COPY	0, infinity	infinity
MOVE	infinity (andere Werte werden ignoriert)	infinity
LOCK	0, infinity	infinity
DELETE	wird 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

Übermittlung von Sperr-Tokens – Nachweis, dass der Client eine Sperre hält
Bedingte Anfragen – Bedingte Ausführung auf Basis von ETags
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

Sperr-Token-Abgleich – Prüft, ob das übermittelte Token mit der Ressourcensperre übereinstimmt
ETag-Abgleich – Prüft, ob das Entity-Tag übereinstimmt
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

Header	Verwendete Methoden	Pflicht/Optional	Beschreibung
DAV	OPTIONS	Antwort	Unterstützte Konformitätsstufen des Servers
Depth	PROPFIND, COPY, LOCK	Optional	Tiefe der Operation
Destination	COPY, MOVE	Pflicht	Ziel-URL
If	Alle Methoden	Optional	Bedingte Ausführung und Sperr-Token-Übermittlung
Lock-Token	UNLOCK	Pflicht	Zu entfernendes Sperr-Token
Overwrite	COPY, MOVE	Optional	Ziel überschreiben oder nicht
Timeout	LOCK	Optional	Vorgeschlagene 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.