11. Status Code Extensions to HTTP/1.1 (Extensions de codes de statut pour HTTP/1.1)

Les codes de statut suivants sont ajoutés à ceux définis dans HTTP/1.1 [RFC2616].

11.1 207 Multi-Status (Multi-Statut)

Le code de statut 207 (Multi-Status, Multi-Statut) fournit un statut pour plusieurs opérations indépendantes (voir Section 13 pour plus d'informations).

11.2 422 Unprocessable Entity (Entité non traitable)

Le code de statut 422 (Unprocessable Entity, Entité non traitable) signifie que le serveur comprend le type de contenu de l'entité de requête (donc un code de statut 415(Unsupported Media Type) est inapproprié), et que la syntaxe de l'entité de requête est correcte (donc un code de statut 400 (Bad Request) est inapproprié) mais n'a pas pu traiter les instructions contenues. Par exemple, cette condition d'erreur peut se produire si un corps de requête XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes), mais sémantiquement erronées.

11.3 423 Locked (Verrouillé)

Le code de statut 423 (Locked, Verrouillé) signifie que la ressource source ou destination d'une méthode est verrouillée. Cette réponse DEVRAIT contenir un code de précondition ou de postcondition approprié, tel que 'lock-token-submitted' ou 'no-conflicting-lock'.

11.4 424 Failed Dependency (Dépendance échouée)

Le code de statut 424 (Failed Dependency, Dépendance échouée) signifie que la méthode n'a pas pu être exécutée sur la ressource car l'action demandée dépendait d'une autre action et que cette action a échoué. Par exemple, si une commande dans une méthode PROPPATCH échoue, alors, au minimum, le reste des commandes échouera également avec 424 (Failed Dependency).

11.5 507 Insufficient Storage (Stockage insuffisant)

Le code de statut 507 (Insufficient Storage, Stockage insuffisant) signifie que la méthode n'a pas pu être exécutée sur la ressource car le serveur est incapable de stocker la représentation nécessaire pour terminer avec succès la requête. Cette condition est considérée comme temporaire. Si la requête qui a reçu ce code de statut était le résultat d'une action utilisateur, la requête NE DOIT PAS être répétée jusqu'à ce qu'elle soit demandée par une action utilisateur séparée.

12. Use of HTTP Status Codes (Utilisation des codes de statut HTTP)

Ces codes HTTP ne sont pas redéfinis, mais leur utilisation est quelque peu étendue par les méthodes et les exigences WebDAV. En général, de nombreux codes de statut HTTP peuvent être utilisés en réponse à n'importe quelle requête, pas seulement dans les cas décrits dans ce document. Notez également que les serveurs WebDAV sont connus pour utiliser des réponses de redirection de niveau 300 (et les premiers tests d'interopérabilité ont trouvé des clients non préparés à voir ces réponses). Une réponse de niveau 300 NE DOIT PAS être utilisée lorsque le serveur a créé une nouvelle ressource en réponse à la requête.

12.1 412 Precondition Failed (Échec de la précondition)

Toute requête peut contenir un en-tête conditionnel défini dans HTTP (If-Match, If-Modified-Since, etc.) ou les en-têtes conditionnels "If" ou "Overwrite" définis dans cette spécification. Si le serveur évalue un en-tête conditionnel et si cette condition ne tient pas, alors ce code d'erreur DOIT être retourné. D'autre part, si le client n'a pas inclus d'en-tête conditionnel dans la requête, alors le serveur NE DOIT PAS utiliser ce code de statut.

12.2 414 Request-URI Too Long (URI de requête trop long)

Ce code de statut est utilisé dans HTTP 1.1 uniquement pour les Request-URIs, pas pour les URI dans d'autres emplacements.

13. Multi-Status Response (Réponse Multi-Statut)

Une réponse Multi-Status transmet des informations sur plusieurs ressources dans des situations où plusieurs codes de statut 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 de statut des séries 200, 300, 400 et 500 générés pendant l'invocation de la méthode. Les codes de statut de la série 100 NE DEVRAIENT PAS être enregistrés dans un élément XML 'response'.

Bien que '207' soit utilisé comme code de statut de réponse global, le destinataire doit consulter le contenu du corps de réponse multistatus pour plus d'informations 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 également 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 le statut:

Un élément 'status' en tant qu'enfant de l'élément 'response' indique le statut de l'exécution du message pour la ressource identifiée dans son ensemble (par exemple, voir Section 9.6.2). Certaines définitions de méthode fournissent des informations sur les codes de statut 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 de statut, 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 enfant 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 pas d'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 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 de statut internes)

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