424 Failed Dependency

Utilisation

L’erreur 424 Failed Dependency fait partie de Webdav, utilisé comme système de fichiers au-dessus de HTTP. Lorsque cette erreur est reçue, le code apparaît dans le corps du message, au sein d’une réponse 207 Multi-Status. C’est un exemple de réponse réussie contenant une indication d’échec.

Il revient au client d’analyser la réponse multi-statuts et, lorsqu’il y découvre des erreurs 424 Failed Dependency, de déterminer le problème et de le résoudre en conséquence.

Ce statut est rencontré lors d’une opération PROPPATCH, où plusieurs propriétés sont modifiées en une seule fois dans une même requête HTTP. En règle générale, une requête HTTP réussit ou échoue dans son ensemble. Si l’une des propriétés ne parvient pas à être définie, la requête entière échoue. Pour les propriétés définies avec succès avant l’échec, le statut 424 Failed Dependency est utilisé.

Impact SEO

Les moteurs de recherche comme Google n’indexeront pas une URL dont la réponse porte le statut 424. Les URL précédemment indexées qui renvoient ce code de statut seront retirées des résultats de recherche.

Exemple

Le client soumet une requête pour mettre à jour les numéros de sièges et le nom d’un enregistrement d’inscription à une conférence. Après l’inscription initiale, des sièges peuvent être ajoutés, retirés ou modifiés. Aucune modification du nom n’est autorisée. Comme le changement de nom est refusé par un 403 Forbidden, la requête entière est refusée, ce qui signifie que les mises à jour de la répartition des sièges ne sont pas effectuées.

Requête

PROPPATCH /update.html HTTP/1.1
Host: example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: 305

<?xml version="1.0" encoding="utf-8" ?>
<d:propertyupdate xmlns:d="DAV:"
                  xmlns:z="urn:example">
  <d:set>
    <d:prop>
      <z:seats>
        <z:seatnumber>100</z:seatnumber>
        <z:seatnumber>101</z:seatnumber>
      </z:seats>
    </d:prop>
    <d:prop>
      <d:name>Smith</d:name>
    </d:prop>
  </d:set>
</d:propertyupdate>

Réponse

HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: 528

<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:"
               xmlns:z="urn:example">
  <d:response>
    <d:href>
      http://example.com/registrants/update.html
    </d:href>
    <d:propstat>
      <d:prop><z:seats/></d:prop>
      <d:status>
        HTTP/1.1 424 Failed Dependency
      </d:status>
    </d:propstat>
    <d:propstat>
      <d:prop><z:name/></d:prop>
      <d:status>HTTP/1.1 403 Forbidden</d:status>
    </d:propstat>
    <d:responsedescription>
      The name of the registrant is not modifiable.
    </d:responsedescription>
  </d:response>
</d:multistatus>

Comment corriger

Analysez le corps de la réponse 207 Multi-Status et repérez la sous-requête portant un code d’échec autre que 424. Les entrées 424 sont des échecs en cascade. La cause racine est l’opération présentant une erreur différente, telle que 403, 409 ou 423.

Corrigez d’abord l’opération à l’origine du problème. Dans une requête PROPPATCH, une seule mise à jour de propriété qui échoue avec 403 Forbidden fait échouer avec 424 toutes les autres mises à jour de propriétés de la même requête. Réglez le cas de la propriété interdite (retirez le champ fautif ou corrigez les permissions), puis relancez l’intégralité du PROPPATCH.

Vérifiez la présence de verrous sur la ressource. Un statut 423 Locked sur une sous-requête se propage en 424 à toutes les autres opérations du lot. Déverrouillez la ressource ou incluez le bon jeton de verrou dans l’en-tête If avant de réessayer.

L’ordre a son importance dans certaines implémentations Webdav. Placez les opérations indépendantes en premier et les opérations dépendantes en dernier, afin que les échecs partiels touchent moins d’éléments.

Découpez les requêtes par lots volumineuses en groupes plus petits lors du débogage. Isoler les opérations individuelles rend visible la véritable dépendance défaillante sans avoir à analyser une réponse multi-statuts complexe.

Côté serveur, renvoyez des messages d’erreur descriptifs dans chaque élément <d:responsedescription> afin que les clients identifient la propriété ou la ressource défaillante sans deviner.

Références de code

.NET

HttpStatusCode.FailedDependency

Rust

http::StatusCode::FAILED_DEPENDENCY

Rails

:failed_dependency

http.StatusFailedDependency

Symfony

Response::HTTP_FAILED_DEPENDENCY

Python3.5+

http.HTTPStatus.FAILED_DEPENDENCY

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_FAILED_DEPENDENCY

Angular

@angular/common/http/HttpStatusCode.FailedDependency