13. Multi-Status Response (Réponse multi-états)

Une réponse Multi-Status transmet des informations sur plusieurs ressources dans des situations où plusieurs codes d'état pourraient être appropriés. Le corps de réponse Multi-Status par défaut est une entité HTTP text/xml ou application/xml avec un élément racine 'multistatus'. D'autres éléments contiennent des codes d'état des séries 200, 300, 400 et 500 générés lors de l'invocation de la méthode. Les codes d'état de la série 100 NE DEVRAIENT PAS être enregistrés dans un élément XML 'response'.

Bien que '207' soit utilisé comme code d'état de réponse global, le destinataire doit consulter le contenu du corps de réponse multistatus pour obtenir des informations supplémentaires sur le succès ou l'échec de l'exécution de la méthode. La réponse PEUT être utilisée dans des situations de succès, de succès partiel et aussi d'échec.

L'élément racine 'multistatus' contient zéro ou plusieurs éléments 'response' dans n'importe quel ordre, chacun avec des informations sur une ressource individuelle. Chaque élément 'response' DOIT avoir un élément 'href' pour identifier la ressource.

Une réponse Multi-Status utilise l'un des deux formats distincts pour représenter l'état:

Un élément 'status' en tant qu'enfant de l'élément 'response' indique l'état de l'exécution du message pour la ressource identifiée dans son ensemble (par exemple, voir la section 9.6.2). Certaines définitions de méthodes fournissent des informations sur les codes d'état spécifiques que les clients devraient être préparés à voir dans une réponse. Cependant, les clients DOIVENT être capables de gérer d'autres codes d'état, en utilisant les règles génériques définies dans la section 10 de [RFC2616].
Pour PROPFIND et PROPPATCH, le format a été étendu en utilisant l'élément 'propstat' au lieu de 'status', fournissant des informations sur les propriétés individuelles d'une ressource. Ce format est spécifique à PROPFIND et PROPPATCH, et est décrit en détail dans les sections 9.1 et 9.2.

13.1. Response Headers (En-têtes de réponse)

HTTP définit l'en-tête Location pour indiquer une URL préférée pour la ressource qui a été adressée dans le Request-URI (par exemple, en réponse à des requêtes PUT réussies ou dans des réponses de redirection). Cependant, l'utilisation de cet en-tête crée une ambiguïté lorsqu'il y a des URL dans le corps de la réponse, comme avec Multi-Status. Ainsi, l'utilisation de l'en-tête Location avec la réponse Multi-Status est intentionnellement non définie.

13.2. Handling Redirected Child Resources (Gestion des ressources enfants redirigées)

Les réponses de redirection (300-303, 305 et 307) définies dans HTTP 1.1 prennent normalement un en-tête Location pour indiquer le nouvel URI pour la ressource unique redirigée depuis le Request-URI. Les réponses Multi-Status contiennent de nombreuses adresses de ressources, mais la définition originale dans [RFC2518] n'avait aucun endroit pour que le serveur fournisse le nouvel URI pour les ressources redirigées. Cette spécification définit un élément 'location' pour cette information (voir la section 14.9). Les serveurs DOIVENT utiliser ce nouvel élément avec les réponses de redirection dans Multi-Status.

Les clients rencontrant des ressources redirigées dans Multi-Status NE DOIVENT PAS compter sur la présence de l'élément 'location' avec un nouvel URI. Si l'élément n'est pas présent, le client PEUT réémettre la requête vers la ressource redirigée individuelle, car la réponse à cette requête peut être redirigée avec un en-tête Location contenant le nouvel URI.

13.3. Internal Status Codes (Codes d'état internes)

Les sections 9.2.1, 9.1.2, 9.6.1, 9.8.3 et 9.9.2 définissent divers codes d'état utilisés dans les réponses Multi-Status. Cette spécification ne définit pas la signification des autres codes d'état qui pourraient apparaître dans ces réponses.