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 200-, 300-, 400- und 500-Serien-Statuscodes, die während des Methodenaufrufs generiert wurden. Statuscodes der 100-Serie SOLLTEN NICHT in einem 'response'-XML-Element aufgezeichnet werden.

Obwohl '207' als Gesamtantwortstatuscode 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 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 zeigt den Status der Nachrichtenausführung für die identifizierte Ressource als Ganzes an (siehe beispielsweise Abschnitt 9.6.2). Einige Methodendefinitionen bieten Informationen über spezifische Statuscodes, auf die Clients in einer Antwort vorbereitet sein sollten. Clients MÜSSEN jedoch in der Lage sein, andere Statuscodes zu verarbeiten, unter Verwendung der allgemeinen Regeln, die in Abschnitt 10 von [RFC2616] definiert sind.
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 (Antwort-Header)

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 Umleitungsantworten). 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 (Umgang mit umgeleiteten Kindressourcen)

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

Clients, die auf umgeleitete Ressourcen in Multi-Status stoßen, DÜRFEN NICHT darauf vertrauen, dass das 'location'-Element mit einem neuen URI vorhanden ist. Wenn das Element nicht vorhanden ist, KANN der Client die Anfrage an die einzelne umgeleitete Ressource erneut stellen, da die Antwort auf diese Anfrage mit einem Location-Header umgeleitet werden kann, der den neuen 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.