8. General Request and Response Handling (Allgemeine Anfragen- und Antwortbehandlung)

8.1 Precedence in Error Handling (Vorrang bei der Fehlerbehandlung)

Server MÜSSEN Autorisierungsfehler vor anderen Fehlern zurückgeben. Dies vermeidet das Durchsickern von Informationen über geschützte Ressourcen (z. B. ein Client, der feststellt, dass eine versteckte Ressource existiert, indem er eine 423 Locked-Antwort auf eine anonyme Anfrage an die Ressource sieht).

8.2 Use of XML (Verwendung von XML)

In HTTP/1.1 wurden Methodenparameterinformationen ausschließlich in HTTP-Headern codiert. Im Gegensatz zu HTTP/1.1 codiert WebDAV Methodenparameterinformationen entweder in einem XML-Anfrage-Entity-Body ([REC-XML]) oder in einem HTTP-Header. Die Verwendung von XML zur Codierung von Methodenparametern wurde durch die Fähigkeit motiviert, zusätzliche XML-Elemente zu bestehenden Strukturen hinzuzufügen, um Erweiterbarkeit bereitzustellen; und durch die Fähigkeit von XML, Informationen in ISO 10646-Zeichensätzen zu codieren, um Internationalisierungsunterstützung bereitzustellen.

Zusätzlich zur Codierung von Methodenparametern wird XML in WebDAV verwendet, um die Antworten von Methoden zu codieren, wodurch die Erweiterungs- und Internationalisierungsvorteile von XML für Methodenausgabe sowie -eingabe bereitgestellt werden.

Wenn XML für einen Anfrage- oder Antwortkörper verwendet wird, SOLLTE der Content-Type-Typ application/xml sein. Implementierungen MÜSSEN sowohl text/xml als auch application/xml in Anfrage- und Antwortkörpern akzeptieren. Die Verwendung von text/xml ist veraltet.

Alle DAV-konformen Clients und Ressourcen MÜSSEN XML-Parser verwenden, die mit [REC-XML] und [REC-XML-NAMES] konform sind. Alle in Anfragen oder Antworten verwendeten XML MÜSSEN mindestens wohlgeformt sein und Namensräume korrekt verwenden. Wenn ein Server XML erhält, das nicht wohlgeformt ist, MUSS der Server die gesamte Anfrage mit 400 (Bad Request) ablehnen. Wenn ein Client XML erhält, das in einer Antwort nicht wohlgeformt ist, DARF der Client nichts über das Ergebnis der ausgeführten Methode annehmen und SOLLTE den Server als fehlerhaft behandeln.

Beachten Sie, dass die Verarbeitung von XML, das von einer nicht vertrauenswürdigen Quelle übermittelt wurde, Risiken im Zusammenhang mit Datenschutz, Sicherheit und Servicequalität verursachen kann (siehe Abschnitt 20). Server KÖNNEN fragwürdige Anfragen ablehnen (auch wenn sie aus wohlgeformtem XML bestehen), beispielsweise mit einem 400 (Bad Request)-Statuscode und einem optionalen Antwortkörper, der das Problem erklärt.

8.3 URL Handling (URL-Behandlung)

URLs erscheinen an vielen Stellen in Anfragen und Antworten. Interoperabilitätserfahrungen mit [RFC2518] zeigten, dass viele Clients, die Multi-Status-Antworten parsen, die vollständige Referenzauflösung, die in Abschnitt 5 von [RFC3986] definiert ist, nicht vollständig implementiert haben. Daher müssen Server insbesondere bei der Behandlung von URLs in Antworten vorsichtig sein, um sicherzustellen, dass Clients genügend Kontext haben, um alle URLs interpretieren zu können. Die Regeln in diesem Abschnitt gelten nicht nur für Ressourcen-URLs im 'href'-Element in Multi-Status-Antworten, sondern auch für die Destination- und If-Header-Ressourcen-URLs.

Der Sender hat die Wahl zwischen zwei Ansätzen: Verwendung einer relativen Referenz, die gegen den Request-URI aufgelöst wird, oder eines vollständigen URI. Ein Server MUSS sicherstellen, dass jeder 'href'-Wert innerhalb einer Multi-Status-Antwort dasselbe Format verwendet.

WebDAV verwendet in seinen Erweiterungen nur eine Form relativer Referenz, den absoluten Pfad.

Simple-ref = absolute-URI | ( path-absolute [ "?" query ] )

Die Produktionen absolute-URI, path-absolute und query sind in den Abschnitten 4.3, 3.3 und 3.4 von [RFC3986] definiert.

Innerhalb von Simple-ref-Produktionen DÜRFEN Sender NICHT:

Punkt-Segmente ("." oder "..") verwenden, oder
Präfixe haben, die nicht mit dem Request-URI übereinstimmen (unter Verwendung der in Abschnitt 3.2.3 von [RFC2616] definierten Vergleichsregeln).

Bezeichner für Sammlungen SOLLTEN mit einem '/'-Zeichen enden.

8.3.1 Beispiel - Korrekte URL-Behandlung

Betrachten Sie die Sammlung http://example.com/sample/ mit der internen Mitglieds-URL http://example.com/sample/a%20test und der PROPFIND-Anfrage unten:

Anfrage:

PROPFIND /sample/ HTTP/1.1
Host: example.com
Depth: 1

In diesem Fall sollte der Server zwei 'href'-Elemente zurückgeben, die entweder enthalten

http://example.com/sample/ und http://example.com/sample/a%20test, oder
/sample/ und /sample/a%20test

Beachten Sie, dass, obwohl der Server die Mitgliedsressource intern als 'a test' speichern kann, sie prozentcodiert sein muss, wenn sie innerhalb einer URI-Referenz verwendet wird (siehe Abschnitt 2.1 von [RFC3986]). Beachten Sie auch, dass ein legaler URI immer noch Zeichen enthalten kann, die innerhalb von XML-Zeichendaten maskiert werden müssen, wie das Ampersand-Zeichen.

8.4 Required Bodies in Requests (Erforderliche Körper in Anfragen)

Einige dieser neuen Methoden definieren keine Körper. Server MÜSSEN alle Anfragen auf einen Körper prüfen, auch wenn ein Körper nicht erwartet wurde. In Fällen, in denen ein Anfragekörper vorhanden ist, aber von einem Server ignoriert würde, MUSS der Server die Anfrage mit 415 (Unsupported Media Type) ablehnen. Dies informiert den Client (der möglicherweise versucht hat, eine Erweiterung zu verwenden), dass der Körper nicht wie vom Client beabsichtigt verarbeitet werden konnte.

8.5 HTTP Headers for Use in WebDAV (HTTP-Header zur Verwendung in WebDAV)

HTTP definiert viele Header, die in WebDAV-Anfragen und -Antworten verwendet werden können. Nicht alle sind in allen Situationen angemessen, und einige Interaktionen können undefiniert sein. Beachten Sie, dass HTTP 1.1 den Date-Header in allen Antworten erfordert, wenn möglich (siehe Abschnitt 14.18, [RFC2616]).

Der Server MUSS Autorisierungsprüfungen durchführen, bevor er einen bedingten HTTP-Header prüft.

8.6 ETag

HTTP 1.1 empfiehlt die Verwendung von ETags anstelle von Änderungsdaten zur Cache-Steuerung, und es gibt noch stärkere Gründe, ETags für die Erstellung vorzuziehen. Die korrekte Verwendung von ETags ist in einer verteilten Erstellungsumgebung noch wichtiger, da ETags zusammen mit Sperren erforderlich sind, um das Problem verlorener Updates zu vermeiden. Ein Client könnte beispielsweise eine Sperre nicht erneuern, wenn die Sperre abläuft und der Client versehentlich offline ist oder sich mitten in einem langen Upload befindet. Wenn ein Client die Sperre nicht erneuern kann, ist es durchaus möglich, dass die Ressource immer noch neu gesperrt werden kann und der Benutzer mit der Bearbeitung fortfahren kann, solange in der Zwischenzeit keine Änderungen vorgenommen wurden. ETags sind erforderlich, damit der Client diesen Fall unterscheiden kann. Andernfalls ist der Client gezwungen, den Benutzer zu fragen, ob er die Ressource auf dem Server überschreiben soll, ohne dem Benutzer sogar sagen zu können, ob sie sich geändert hat. Zeitstempel lösen dieses Problem nicht annähernd so gut wie ETags.

Starke ETags sind für Erstellungsanwendungsfälle viel nützlicher als schwache ETags (siehe Abschnitt 13.3.3 von [RFC2616]). Semantische Äquivalenz kann ein nützliches Konzept sein, aber das hängt vom Dokumenttyp und Anwendungstyp ab, und Interoperabilität könnte eine Vereinbarung oder einen Standard außerhalb des Umfangs dieser Spezifikation und HTTP erfordern. Beachten Sie auch, dass schwache ETags bestimmte Einschränkungen in HTTP haben, z. B. können diese nicht in If-Match-Headern verwendet werden.

Beachten Sie, dass die Bedeutung eines ETag in einer PUT-Antwort weder in diesem Dokument noch in RFC 2616 klar definiert ist (d. h., ob der ETag bedeutet, dass die Ressource Byte-für-Byte äquivalent zum Körper der PUT-Anfrage ist, oder ob der Server bei der Speicherung geringfügige Änderungen an der Formatierung oder dem Inhalt des Dokuments vorgenommen haben könnte). Dies ist ein HTTP-Problem, nicht rein ein WebDAV-Problem.

Da Clients möglicherweise gezwungen sind, Benutzer aufzufordern oder geänderte Inhalte zu verwerfen, wenn sich der ETag ändert, SOLLTE ein WebDAV-Server den ETag (oder die Last-Modified-Zeit) für eine Ressource mit unverändertem Körper und Standort NICHT ändern. Der ETag repräsentiert den Zustand des Körpers oder Inhalts der Ressource. Es gibt keine ähnliche Möglichkeit festzustellen, ob sich Eigenschaften geändert haben.

8.7 Including Error Response Bodies (Einbeziehung von Fehlerantwortkörpern)

HTTP und WebDAV verwendeten die Körper der meisten Fehlerantworten nicht für maschinell analysierbare Informationen, bis die Spezifikation für Versionierungserweiterungen für WebDAV einen Mechanismus einführte, um spezifischere Informationen in den Körper einer Fehlerantwort aufzunehmen (Abschnitt 1.6 von [RFC3253]). Der Fehlerkörpermechanismus ist angemessen für die Verwendung mit jeder Fehlerantwort, die einen Körper aufnehmen kann, aber noch keinen definierten Körper hat. Der Mechanismus ist besonders geeignet, wenn ein Statuscode viele Dinge bedeuten kann (zum Beispiel kann 400 Bad Request bedeuten, dass erforderliche Header fehlen, Header falsch formatiert sind und vieles mehr). Dieser Fehlerkörpermechanismus wird in Abschnitt 16 behandelt.

8.8 Impact of Namespace Operations on Cache Validators (Auswirkung von Namespace-Operationen auf Cache-Validatoren)

Beachten Sie, dass die HTTP-Antwortheader "Etag" und "Last-Modified" (siehe [RFC2616], Abschnitte 14.19 und 14.29) pro URL (nicht pro Ressource) definiert sind und von Clients zum Caching verwendet werden. Daher müssen Server sicherstellen, dass die Ausführung jeder Operation, die den URL-Namespace betrifft (wie COPY, MOVE, DELETE, PUT oder MKCOL), ihre Semantik beibehält, insbesondere:

Für jede gegebene URL MUSS der "Last-Modified"-Wert jedes Mal inkrementiert werden, wenn sich die bei GET zurückgegebene Darstellung ändert (innerhalb der Grenzen der Zeitstempelauflösung).
Für jede gegebene URL DARF ein "ETag"-Wert NICHT für verschiedene von GET zurückgegebene Darstellungen wiederverwendet werden.

In der Praxis bedeutet dies, dass Server

möglicherweise "Last-Modified"-Zeitstempel für jede Ressource innerhalb des Ziel-Namespace einer Namespace-Operation inkrementieren müssen, es sei denn, sie können dies selektiver tun, und
ähnlich möglicherweise "ETag"-Werte für diese Ressourcen neu zuweisen müssen (es sei denn, der Server weist Entity-Tags so zu, dass sie im gesamten vom Server verwalteten URL-Namespace eindeutig sind).

Beachten Sie, dass diese Überlegungen auch für spezifische Anwendungsfälle gelten, wie z. B. die Verwendung von PUT zum Erstellen einer neuen Ressource an einer URL, die zuvor zugeordnet war, aber seitdem gelöscht wurde.