HTTP — tous les codes de statut

Avec Expect: 100-continue, envoyer le corps après cette réponse provisoire ; attendre ensuite le statut final.

Vérifier Upgrade et Connection. Ce mécanisme ne s’utilise pas de la même façon en HTTP/2 ou HTTP/3.

Ne pas confondre avec 202, qui est une réponse finale. Usage historique défini par la RFC 2518.

Exemple : Link: </style.css>; rel=preload; as=style. Attendre le statut final avant de conclure au succès.

Enregistrement temporaire, expiration prévue le 13 novembre 2026. Vérifier le registre et la version du protocole avant usage.

Exemple : GET /api/articles renvoie la liste. Vérifier aussi le schéma du corps avant de l’utiliser.

Exemple : POST /api/articles. Fournir Location: /api/articles/42 pour identifier la ressource créée lorsque pertinent.

Exemple : export en arrière-plan. Fournir une URL de suivi ; ne pas annoncer que le fichier est déjà prêt.

Examiner le proxy et les transformations ; tenir compte de leur effet sur les validations de cache.

Exemple : suppression réussie. Ne pas appeler response.json() sur ce corps vide.

Exemple : vider un formulaire après son envoi. La réponse ne contient pas de contenu.

Exemple : téléchargement reprenant à l’octet 1000. Vérifier Range, Content-Range et les validateurs.

Lire chaque statut dans le document multistatus : un 207 n’implique pas que toutes les opérations ont réussi.

Traiter les éléments déjà décrits sans les compter deux fois ; ce code apparaît dans le corps multistatus.

Vérifier la négociation A-IM et l’en-tête IM avant de reconstruire la représentation.

Présenter les choix au client et éventuellement indiquer une préférence dans Location.

Mettre à jour les liens. Certains clients transforment POST en GET ; utiliser 308 si la méthode doit être conservée.

Vérifier Location. Certains clients transforment POST en GET ; utiliser 307 pour conserver la méthode et le corps.

Après un formulaire POST, rediriger vers une page de confirmation avec Location ; une requête HEAD peut rester HEAD.

Réutiliser le corps en cache et actualiser ses métadonnées. Le 304 ne contient pas de contenu de réponse.

Ne pas l’émettre dans une nouvelle API. Configurer les proxys par les mécanismes du client.

Ne pas l’attribuer à une nouvelle signification dans une API publique.

Un POST reste un POST. Vérifier la destination Location avant d’y renvoyer des données.

Choisir ce code pour déplacer durablement un endpoint dont les appels POST doivent être conservés.

Exemple : JSON mal formé. Vérifier URL, corps et en-têtes ; retourner un message précis sur l’entrée invalide.

Vérifier Authorization, expiration du jeton et cookies. Le serveur doit fournir WWW-Authenticate avec un défi applicable.

Si une API l’utilise pour un paiement ou un quota, lire son contrat spécifique au fournisseur.

Vérifier rôle, permissions et politique d’accès. Répéter les mêmes identifiants ne résout généralement rien.

Vérifier chemin, identifiant, route et environnement. Ce code ne dit pas si l’absence est permanente.

Exemple : POST sur une route en lecture seule. Le serveur doit envoyer Allow avec les méthodes acceptées.

Vérifier Accept et Accept-Language ; demander un format réellement proposé par l’API.

Examiner Proxy-Authenticate et configurer Proxy-Authorization pour le proxy concerné.

Vérifier réseau et vitesse d’envoi. Une nouvelle tentative peut utiliser une nouvelle connexion, selon la sûreté de l’opération.

Exemple : nom déjà pris ou version incompatible. Récupérer l’état actuel et résoudre le conflit avant de renvoyer.

Retirer les liens obsolètes ou proposer un remplacement. Préférer 404 si la permanence n’est pas connue.

Fournir un Content-Length correct lorsque possible ; ne pas inventer une taille qui ne correspond pas au corps.

Exemple : If-Match utilise un ancien ETag. Relire la ressource avant de retenter la modification.

Réduire le fichier ou vérifier les limites du proxy et de l’application. Une limite temporaire peut être accompagnée de Retry-After.

Réduire les paramètres ; déplacer une recherche volumineuse vers un corps POST si l’API le permet.

Vérifier Content-Type, Content-Encoding et le corps réel. Exemple : envoyer du JSON à une route qui attend du multipart.

Vérifier la taille actuelle du fichier et Range. Pour une plage d’octets non satisfaisable, examiner Content-Range: bytes */taille.

Si Expect: 100-continue est en cause, envisager une nouvelle requête sans cette attente.

Ne pas utiliser comme erreur métier générique. La référence historique est la RFC 2324 ; le registre actuel indique Unused.

Vérifier Host, SNI et le routage des connexions mutualisées ; une autre connexion peut être nécessaire.

Exemple : date de fin antérieure au début. Corriger les champs signalés par la validation métier.

Vérifier le propriétaire du verrou et le jeton transmis ; libérer le verrou ou attendre selon le protocole.

Chercher l’échec initial dans la réponse multistatus et corriger d’abord cette dépendance.

Réessayer après la négociation TLS, sans early data. Ce n’est pas un code de limitation de débit.

Lire l’en-tête Upgrade requis dans la réponse et utiliser le protocole proposé si le client le prend en charge.

Récupérer l’ETag puis envoyer If-Match. Distinguer condition absente (428) et condition échouée (412).

Respecter Retry-After s’il est présent ; espacer les tentatives avec attente progressive et aléatoire, puis vérifier les quotas.

Réduire cookies et jetons inutiles ; vérifier les limites du serveur et du proxy.

Lire les explications et, s’il est fourni, le lien rel=blocked-by identifiant l’entité qui applique le blocage.

Corréler l’heure et l’identifiant de requête avec les journaux ; vérifier exception, configuration et dépendances.

Vérifier les capacités de l’API. Une méthode connue mais interdite sur une route relève plutôt de 405.

Vérifier l’application derrière le proxy, ses journaux et la validité de sa réponse HTTP.

Vérifier capacité et état du service ; respecter Retry-After s’il est présent et éviter une boucle de tentatives immédiates.

Examiner latence applicative, requêtes SQL et délais entre services avant d’augmenter les timeouts.

Configurer une version HTTP compatible dans le client ou le proxy.

Corriger la configuration des variantes pour que la sélection aboutisse à une ressource finale.

Vérifier espace disque et quotas ; une répétition immédiate sans changement ne libère pas de stockage.

Examiner les liaisons entre collections. Ce code ne signifie pas simplement trop de redirections dans un navigateur.

Ne pas l’adopter pour une nouvelle API. Vérifier la documentation d’un système historique qui le renvoie.

Ouvrir le portail du réseau. Ne pas envoyer les identifiants de l’API au portail ; il ne s’agit pas d’un 401 de l’origine.

Rafraîchir la session et le jeton CSRF, puis vérifier cookies et domaine de session.

Examiner les règles return 444 et les journaux ; le client ne reçoit pas une ligne de statut 444.

Réduire les en-têtes et vérifier les buffers ; le statut exposé au client peut être différent.

Vérifier le certificat client et sa chaîne de confiance ; ne pas le confondre avec le certificat du serveur.

Configurer le certificat client pour l’authentification TLS mutuelle.

Corriger le schéma de l’URL ou le protocole entre proxy et origine.

Comparer annulations du client et délais des proxys ; ce statut de journal n’est pas envoyé au client déjà parti.

Inspecter les journaux de l’origine et conserver le Ray ID pour corréler l’incident.

Vérifier que le serveur écoute et que le pare-feu accepte les connexions Cloudflare.

Vérifier disponibilité réseau, charge et pare-feu de l’origine.

Vérifier l’adresse IP d’origine dans le DNS et le routage réseau.

Optimiser les traitements longs ou les déplacer en tâche asynchrone avec suivi.

Examiner protocoles, suites cryptographiques, SNI et journaux TLS du serveur.

Corriger expiration, nom d’hôte et chaîne du certificat.

Lire ce code 1xxx pour trouver la cause précise, par exemple un problème DNS ; 530 seul ne suffit pas.