11. Status Code Extensions to HTTP/1.1 (Statuscode-Erweiterungen für HTTP/1.1)

Die folgenden Statuscodes werden zu denen hinzugefügt, die in HTTP/1.1 [RFC2616] definiert sind.

11.1 207 Multi-Status

Der 207 (Multi-Status) Statuscode liefert Status für mehrere unabhängige Operationen (weitere Informationen finden Sie in Abschnitt 13).

11.2 422 Unprocessable Entity (Nicht verarbeitbare Entität)

Der 422 (Unprocessable Entity, Nicht verarbeitbare Entität) Statuscode bedeutet, dass der Server den Inhaltstyp der Anfrage-Entität versteht (daher ist ein 415(Unsupported Media Type) Statuscode unangemessen), und die Syntax der Anfrage-Entität korrekt ist (daher ist ein 400 (Bad Request) Statuscode unangemessen), aber die enthaltenen Anweisungen nicht verarbeiten konnte. Beispielsweise kann diese Fehlerbedingung auftreten, wenn ein XML-Anfrage-Body wohlgeformte (d. h. syntaktisch korrekte), aber semantisch fehlerhafte XML-Anweisungen enthält.

11.3 423 Locked (Gesperrt)

Der 423 (Locked, Gesperrt) Statuscode bedeutet, dass die Quell- oder Zielressource einer Methode gesperrt ist. Diese Antwort SOLLTE einen geeigneten Precondition- oder Postcondition-Code enthalten, wie 'lock-token-submitted' oder 'no-conflicting-lock'.

11.4 424 Failed Dependency (Fehlgeschlagene Abhängigkeit)

Der 424 (Failed Dependency, Fehlgeschlagene Abhängigkeit) Statuscode bedeutet, dass die Methode nicht auf der Ressource ausgeführt werden konnte, weil die angeforderte Aktion von einer anderen Aktion abhing und diese Aktion fehlschlug. Wenn beispielsweise ein Befehl in einer PROPPATCH-Methode fehlschlägt, schlagen mindestens auch die restlichen Befehle mit 424 (Failed Dependency) fehl.

11.5 507 Insufficient Storage (Unzureichender Speicher)

Der 507 (Insufficient Storage, Unzureichender Speicher) Statuscode bedeutet, dass die Methode nicht auf der Ressource ausgeführt werden konnte, weil der Server die Darstellung, die zum erfolgreichen Abschluss der Anfrage erforderlich ist, nicht speichern kann. Diese Bedingung wird als vorübergehend betrachtet. Wenn die Anfrage, die diesen Statuscode erhielt, das Ergebnis einer Benutzeraktion war, DARF die Anfrage NICHT wiederholt werden, bis sie durch eine separate Benutzeraktion angefordert wird.

12. Use of HTTP Status Codes (Verwendung von HTTP-Statuscodes)

Diese HTTP-Codes werden nicht neu definiert, aber ihre Verwendung wird durch WebDAV-Methoden und -Anforderungen etwas erweitert. Im Allgemeinen können viele HTTP-Statuscodes als Antwort auf jede Anfrage verwendet werden, nicht nur in den in diesem Dokument beschriebenen Fällen. Beachten Sie auch, dass WebDAV-Server bekanntermaßen 300-Level-Weiterleitungsantworten verwenden (und frühe Interoperabilitätstests fanden Clients, die nicht darauf vorbereitet waren, diese Antworten zu sehen). Eine 300-Level-Antwort DARF NICHT verwendet werden, wenn der Server als Antwort auf die Anfrage eine neue Ressource erstellt hat.

12.1 412 Precondition Failed (Vorbedingung fehlgeschlagen)

Jede Anfrage kann einen in HTTP definierten bedingten Header (If-Match, If-Modified-Since usw.) oder die in dieser Spezifikation definierten bedingten Header "If" oder "Overwrite" enthalten. Wenn der Server einen bedingten Header auswertet und diese Bedingung nicht erfüllt ist, MUSS dieser Fehlercode zurückgegeben werden. Wenn der Client andererseits keinen bedingten Header in die Anfrage eingeschlossen hat, DARF der Server diesen Statuscode NICHT verwenden.

12.2 414 Request-URI Too Long (Anfrage-URI zu lang)

Dieser Statuscode wird in HTTP 1.1 nur für Request-URIs verwendet, nicht für URIs an anderen Stellen.

13. Multi-Status Response (Multi-Status-Antwort)

Eine Multi-Status-Antwort übermittelt Informationen über mehrere Ressourcen in Situationen, in denen mehrere Statuscodes angemessen sein könnten. Der Standard-Multi-Status-Antwortkörper ist eine text/xml- oder application/xml-HTTP-Entität mit einem 'multistatus'-Wurzelelement. Weitere Elemente enthalten 200er-, 300er-, 400er- und 500er-Serien-Statuscodes, die während der Methodenaufrufs generiert wurden. 100er-Serien-Statuscodes SOLLTEN NICHT in einem 'response'-XML-Element aufgezeichnet werden.

Obwohl '207' als Gesamtantwortstatus code verwendet wird, muss der Empfänger den Inhalt des multistatus-Antwortkörpers konsultieren, um weitere Informationen über den Erfolg oder Misserfolg der Methodenausführung zu erhalten. Die Antwort KANN in Erfolgs-, Teilerfolgs- und auch in Fehlersituationen verwendet werden.

Das 'multistatus'-Wurzelelement enthält null oder mehr 'response'-Elemente in beliebiger Reihenfolge, jedes mit Informationen über eine einzelne Ressource. Jedes 'response'-Element MUSS ein 'href'-Element haben, um die Ressource zu identifizieren.

Eine Multi-Status-Antwort verwendet eines von zwei unterschiedlichen Formaten zur Darstellung des Status:

Ein 'status'-Element als Kind des 'response'-Elements gibt den Status der Nachrichtenausführung für die identifizierte Ressource als Ganzes an (siehe beispielsweise Abschnitt 9.6.2). Einige Methodendefinitionen liefern Informationen über spezifische Statuscodes, auf die Clients vorbereitet sein sollten, sie in einer Antwort zu sehen. Clients MÜSSEN jedoch in der Lage sein, andere Statuscodes zu verarbeiten, indem sie die in Abschnitt 10 von [RFC2616] definierten generischen Regeln verwenden.
Für PROPFIND und PROPPATCH wurde das Format unter Verwendung des 'propstat'-Elements anstelle von 'status' erweitert, um Informationen über einzelne Eigenschaften einer Ressource bereitzustellen. Dieses Format ist spezifisch für PROPFIND und PROPPATCH und wird in den Abschnitten 9.1 und 9.2 ausführlich beschrieben.

13.1 Response Headers (Antwortheader)

HTTP definiert den Location-Header, um eine bevorzugte URL für die Ressource anzugeben, die im Request-URI adressiert wurde (z. B. als Antwort auf erfolgreiche PUT-Anfragen oder in Weiterleitungsantworten). Die Verwendung dieses Headers erzeugt jedoch Mehrdeutigkeit, wenn URLs im Körper der Antwort vorhanden sind, wie bei Multi-Status. Daher ist die Verwendung des Location-Headers mit der Multi-Status-Antwort absichtlich undefiniert.

13.2 Handling Redirected Child Resources (Behandlung weitergeleiteter Kind-Ressourcen)

Weiterleitungsantworten (300-303, 305 und 307), die in HTTP 1.1 definiert sind, nehmen normalerweise einen Location-Header, um die neue URI für die einzelne Ressource anzugeben, die vom Request-URI weitergeleitet wurde. Multi-Status-Antworten enthalten viele Ressourcenadressen, aber die ursprüngliche Definition in [RFC2518] hatte keinen Platz für den Server, um die neue URI für weitergeleitete Ressourcen bereitzustellen. Diese Spezifikation definiert ein 'location'-Element für diese Information (siehe Abschnitt 14.9). Server MÜSSEN dieses neue Element mit Weiterleitungsantworten in Multi-Status verwenden.

Clients, die auf weitergeleitete Ressourcen in Multi-Status stoßen, DÜRFEN NICHT darauf vertrauen, dass das 'location'-Element mit einer neuen URI vorhanden ist. Wenn das Element nicht vorhanden ist, KANN der Client die Anfrage an die einzelne weitergeleitete Ressource erneut ausgeben, da die Antwort auf diese Anfrage mit einem Location-Header weitergeleitet werden kann, der die neue URI enthält.

13.3 Internal Status Codes (Interne Statuscodes)

Die Abschnitte 9.2.1, 9.1.2, 9.6.1, 9.8.3 und 9.9.2 definieren verschiedene Statuscodes, die in Multi-Status-Antworten verwendet werden. Diese Spezifikation definiert nicht die Bedeutung anderer Statuscodes, die in diesen Antworten erscheinen könnten.