Appendix B. Notes on HTTP Client Compatibility (Hinweise zur HTTP-Client-Kompatibilität)
Anhang B. Notes on HTTP Client Compatibility (Hinweise zur HTTP-Client-Kompatibilität)
WebDAV wurde so konzipiert, dass es abwärtskompatibel mit HTTP 1.1 ist, und es hat sich als abwärtskompatibel erwiesen. Die Methoden PUT und DELETE sind in HTTP definiert und können daher sowohl von HTTP-Clients als auch von WebDAV-bewussten Clients verwendet werden, aber die Antworten auf PUT und DELETE wurden in dieser Spezifikation auf eine Weise erweitert, auf die nur ein WebDAV-Client vollständig vorbereitet wäre. Einige theoretische Bedenken wurden darüber geäußert, ob diese Antworten Interoperabilitätsprobleme mit HTTP-only-Clients verursachen würden, und dieser Abschnitt behandelt diese Bedenken.
Da jeder HTTP-Client unerkannte 400-Level- und 500-Level-Statuscodes als Fehler behandeln sollte, sollten die folgenden neuen Statuscodes keine Probleme darstellen: 422, 423 und 507 (424 ist ebenfalls ein neuer Statuscode, erscheint aber nur im Körper einer Multistatus-Antwort.) Wenn also beispielsweise ein HTTP-Client versuchen würde, eine gesperrte Ressource mit PUT oder DELETE zu bearbeiten, sollte die Antwort 423 Locked zu einem allgemeinen Fehler führen, der dem Benutzer präsentiert wird.
Die Antwort 207 Multistatus ist interessant, weil ein HTTP-Client, der eine DELETE-Anfrage an eine Sammlung stellt, eine 207-Antwort als Erfolg interpretieren könnte, obwohl er nicht erkennt, dass die Ressource eine Sammlung ist, und nicht verstehen kann, dass die DELETE-Operation ein vollständiger oder teilweiser Fehler gewesen sein könnte. Diese Interpretation ist nicht vollständig gerechtfertigt, da eine 200-Level-Antwort anzeigt, dass der Server die Anfrage "empfangen, verstanden und akzeptiert" hat, nicht dass die Anfrage zu vollständigem Erfolg geführt hat.
Eine Option ist, dass ein Server einen DELETE einer Sammlung als atomare Operation behandeln könnte und entweder 204 No Content im Erfolgsfall oder eine geeignete Fehlerantwort (400 oder 500 Level) für einen Fehler verwenden könnte. Dieser Ansatz würde tatsächlich die Abwärtskompatibilität maximieren. Da jedoch Interoperabilitätstests und Arbeitsgruppendiskussionen keine Instanzen von HTTP-Clients gefunden haben, die eine DELETE-Anfrage gegen eine WebDAV-Sammlung stellen, ist diese Sorge eher theoretisch als praktisch. Daher werden Server wahrscheinlich vollständig erfolgreich mit HTTP-Clients interoperieren, selbst wenn sie jede Sammlungs-DELETE-Anfrage als WebDAV-Anfrage behandeln und eine 207 Multi-Status-Antwort senden.
Im Allgemeinen werden Server-Implementierungen ermutigt, die detaillierten Antworten und andere in diesem Dokument definierte Mechanismen zu verwenden, anstatt Änderungen aufgrund theoretischer Interoperabilitätsbedenken vorzunehmen.